[Webkit-unassigned] [Bug 69029] Please implement key, char, location and locale properties of KeyboardEvent

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jan 11 15:34:37 PST 2012


https://bugs.webkit.org/show_bug.cgi?id=69029





--- Comment #10 from Aharon (Vladimir) Lanin <aharon at google.com>  2012-01-11 15:34:36 PST ---
(In reply to comment #9)
> What I see in MS Word is that it uses the current keyboard input source to make the decision, not the input source an event came from.

I do not understand the difference.

> > because it's the best signal available for this purpose
> 
> This is not quite true. The only appropriate general signal on OS X is a preference in Language and Text control panel. An application can of course have its own configuration options, but it should not silently ignore system-wide user choice.

For monolingual users, the keyboard language (when provided) is no worse a signal than the system-wide or application-wide language preference (for the UI language), since the monolingual user will have a single keyboard of the same language as the UI preference. For bilingual users, the user's UI language preference has nothing to do with the data that the user is currently entering into the system. I prefer my UI to be in English, but I often type Hebrew and Russian text.

If OS X does not currently provide any way to determine which keyboard the user is using is a missing OS X feature. When running on a platform that does not expose the keyboard language, WebKit is obviously supposed to leave locale undefined (or was it null). The script can detect that and use less reliable signals, e.g. the user's preference for the UI language.

> 
> The fact that this property is wanted to implement incorrect behavior appears to be a strong argument against it.

It is not incorrect. It is heuristic. Generally, it helps a lot more than it hurts. Applications usually provide a way to turn it off for the users who do not like it.

As I said before, we are repeating the discussion that took place in www-dom when this was originally proposed for the spec. The consensus at the end of that was to include it in the spec.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list