This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
As described in https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEProposal.html consider adding getCompositionAlternaties() in InputMethodContext interface. "Returns a copy (per call) of the current list of alternate candidate strings from the InputMethodContext object. The InputMethodContext object can produce alternates while it has a composition in progress. As soon as hasComposition() returns false, then getCompositionAlternatives() will always return an empty list. The list of alternatives is not updated "live"; it is only updated between compositionupdate events." No parameters. Return type: sequence DOMString
Need to be careful with privacy. It is not clear whether user-specific alternatives should be exposed to web page.
Possible solutions to privacy concerns: * Do not send user-defined candidates * Do not send any personalized candidates * Randomize the sequence Possible implementation restriction / optimizations: * Do not send all candidates (some conversion may have hundreds of candidates). Implementation-wise, usually candidate window shows about at most 10 candidates at a time, and the number of the candidates that can be retrieved at once may be limited at the number. At least retrieving all the candidates may block the script execution for unexpectedly long time and better to be avoided.
IME input is disabled for password control, at least on Windows platform, so we don’t need to worry about exposing previous passwords to web apps--however, we know that many sites use other input controls for passwords, so this is still a very real concern. I agree that not sending all candidates is a good limitation to add in the implementation of this API, both for the benefit of performance and usefulness. Usually the top candidates visible for end users are the only things matter for web apps.
We discussed the privacy issue and compared the merit which this API provides and the concerns, we propose this to be dropped from the spec. As an alternative, an API that a user agent might send suggestion data to IME could be possible; e.g IME can show candidates mixed with these suggestions, which is less privacy-critical but still serves similar use case.
Let's defer this for the later version. We should take the privacy issue of this seriously.
Just a quick followup--we have shipped (in IE11 Preview) a version of our proposed IME spec, including the getCompositionAlternatives() API. It passed our internal privacy review. However, we understand that for standardization, it may have a higher bar on privacy. There are a number of mitigations that could be applied to strengthen the privacy aspect of this API such as: * limiting the number of linguistically equivalent alternatives (to say 20?) * generating the list of alternatives any way the UA seems fit such as from standard dictionaries, IME-generated candidates, etc., but with the suggestion that user dictionaries are excluded. * alternatives can be presented in random order Thanks.
Added to Editor's draft: https://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html#widl-InputMethodContext-getCompositionAlternatives-sequence-DOMString at revision https://dvcs.w3.org/hg/ime-api/rev/3311d294f6e1