[whatwg] Exposing spelling/grammar suggestions in contentEditable

[Charles Pritchard]

On 12/3/2010 2:19 PM, Adrian Sutton wrote:
> On 3 Dec 2010, at 22:06, Charles Pritchard wrote:
>> Yes, I understand that.
>>
>> Your statement relates to a defect in the current flexibility of the 
>> "context menu".
>>
>> I fully understand that, you wouldn't need the context menu to be 
>> more flexible, if you had access to suggestions, as you have your own 
>> custom context menu implemented.
>
> That's not the way I see it.  Right now I'm perfectly happy with the 
> complete flexibility I have in the context menu. I don't want to try 
> and tie in with the browser's context menu because that will reduce 
> the flexibility.
I don't think it's fair to assume defeat; the context menu is a high 
level construct it is works as a security mechanism, much like drag and 
drop does.

You have a lot of flexibility with presentation. You do not have 
flexibility with the security model.

>> Recognizing that "suggestions" can not be shared with the DOM, the 
>> alternative is to address defects in the context menu.
>>
>> It seems to me that were the context menu more easily manipulated via 
>> scripting, your use requirement (having suggestions) would be handled 
>> without exposing the suggestions to the DOM.
>
> If I were able to script the context menu, and the context menu 
> contains the spelling suggestions then the spelling suggestions are 
> effectively in the DOM.
You'd be able to add and remove elements, but not "peek" at the content 
within a pre-existing element.

That is, you wouldn't know that "View source..." says View source; you 
would be able to deactivate it though,
whatever it's caption reads.

>> Still, your use case does require that spelling ranges be made available.
>
> If I use the current approach of replacing the context menu then yes. 
>  If I'm scripting an existing context menu then no - if it's a 
> spelling error the suggestions will already be in the context menu and 
> I won't need to do anything special with them (but I would have to 
> remove every *other* menu and add my own custom ones).
>
> I really don't see why if spelling suggestions are a security/privacy 
> concern this couldn't be an opt-in feature like local storage is. That 
> said, I've also not been convinced of the privacy or security concerns 
> beyond just making sure you don't run a buggy/insecure spell checker 
> (much like you shouldn't run a buggy/insecure browser).  As has been 
> noted, the information such as user language and OS/Browser type is 
> pretty trivial to determine through a range of other means.
The possibility of fishing out saved information is too great.

I might for instance, script a set of numbers, and if you've added it to 
your suggestions, I could get your home address.

The window for abuse by exposing only the text range is much smaller.

Again, I'd say that your issue is about context menus. You are using a 
completely custom context menu: but it is still a context menu.

This technical distinction is important for long term work. Consider 
that your context menu may be run in a sandbox.
Think something like WebWorkers, but with only unidirectional 
communication, and a limited dom.

As for the privacy issue on exposing suggestions: I think that there 
should be a reasonable amount of caution.
Yes, spelling suggestions could be a privacy setting, but I think you're 
more likely to see it as a security setting with browser extensions, and 
not in the untrusted window DOM.