Bug 69029

After going through code I have few below observations: The new spec say for "char" http://www.w3.org/TR/DOM-Level-3-Events/#events-KeyboardEvent-char In Current KeyboardEvent.idl we have charcode which actually does the same but instead of returning DOMString returns long value. [ref] readonly attribute long charCode; The new spec say for "key" http://www.w3.org/TR/DOM-Level-3-Events/#events-KeyboardEvent-key In Current KeyboardEvent.idl we have keyCode which actually does the same but instead of returning DOMString returns long value. [ref] readonly attribute long keyCode; similarly for "location" there is "keyLocation" with same return type as spec says(unsigned long). So as char, key and location already present there so we need to change their return type & name to match with spec..? The reason we are getting logs as undefined is we are using event.char & event.location instead if we use event.charCode & event.keyLocation it gives proper logs. Please let me know if I need to investigate more.

Sorry I forgot to mention about "locale" property. This yet needs to be added to KeyboardEvent.idl I have ready patch for this if we agree with above comments I would like to share it.

I honestly don't know if we should rush to implement these new additions to the spec soon. The spec keeps changing, and we ended up supporting obsolete incompatible propertied like keyLocation and keyIdentifier because we tried to follow it. I think that we should consider each of these properties on their merits. Do char and key solve any real problem, so that sites would start using it even if WebKit were the only engine to provide it? Does location have any value at all?

> Does location have any value at all? Sorry for the typo, I meant to ask about locale. That seems most questionable of the batch.

(In reply to comment #3) > I honestly don't know if we should rush to implement these new additions to the spec soon. > > The spec keeps changing, and we ended up supporting obsolete incompatible propertied like keyLocation and keyIdentifier because we tried to follow it. > > I think that we should consider each of these properties on their merits. Do char and key solve any real problem, so that sites would start using it even if WebKit were the only engine to provide it? Does location have any value at all? I completely agree with Alexey here. Locale support is not there in any of the browser yet & tt is not seen that a real-page using "locale". Secondly It is observed that majority of browsers like Webkit, IE, Firefox & Opera does support these properties but with names charCode(instead of char), keyCode(instead of key) & keyLocation(instead of location).

Regarding locale: 1. IE9 supports it. 2. It would be useful in online editors, for things like choosing language-specific quote marks, language-specific digits, and inline directionality changes. Word uses this exact signal for two out of the three above; online editors should be able to do the same. 3. As far as I know, the spec for the locale property has been stable for about a year. BTW, this also applies to TextEvent and CompositionEvent.

> 2. It would be useful in online editors, for things like choosing language-specific quote marks, language-specific digits, and inline directionality changes. Word uses this exact signal for two out of the three above; online editors should be able to do the same. This sounds like a way to write very unreliable applications. Any heuristic based on current input source would fail when the input source doesn't provide such information - like input scripting or Character panel. In fact, I'm not sure if any OS X input sources provide language information. Language specific quote marks and digits in particular would misbehave when using a U.S. English layout to type French (which is a perfectly normal and comfortable configuration).

(In reply to comment #7) > > 2. It would be useful in online editors, for things like choosing language-specific quote marks, language-specific digits, and inline directionality changes. Word uses this exact signal for two out of the three above; online editors should be able to do the same. > > This sounds like a way to write very unreliable applications. Any heuristic based on current input source would fail when the input source doesn't provide such information - like input scripting or Character panel. In fact, I'm not sure if any OS X input sources provide language information. > > Language specific quote marks and digits in particular would misbehave when using a U.S. English layout to type French (which is a perfectly normal and comfortable configuration). Nevertheless, that is precisely the way Microsoft Word works. Open a document, and type: he said "hello" You will get: He said “hello” Now, change the keyboard language to French. Type the same thing again (press the key labeled "3" on your English keyboard to get a quote on the French keyboard). You will get: He said « hello » Why does it choose to use such an unreliable way to do this? Because no one will have a heart attack if it happens to get the wrong quotes, and because it's the best signal available for this purpose (outside of doing expensive text analysis to determine the actual language that the user has been typing). If the leading commercially sold word processor thinks that it's kosher to do this, do we really want to prevent someone writing an online editor from doing the same? In any case, www-dom went through all of these discussions when we originally proposed this property. You can see them at http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0024.html, just keep clicking "Next in Thread".

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. > 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. The fact that this property is wanted to implement incorrect behavior appears to be a strong argument against it.

(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.

> > 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. The difference manifests itself as a bug in MS Word. When you use Character Viewer to input a glyph for straight quote (U+0022), Word converts it to a French quote, mistakenly thinking that the input came from a French source. A glyph selected in Character Viewer is what the user wants to be inserted verbatim. > I prefer my UI to be in English, but I often type Hebrew and Russian text. I think that you misunderstood what system-wide preference I was talking about. There is a preference to select quote style, and it should be honored. I'll attach a screenshot. The preference may not work perfectly yet (e.g., there isn't even an option for secondary quote style that's appropriate for Russian), but following platform behavior is what editing in a browser should do. > 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. Leaving such details to web application authors is really undesirable. Whenever possible, we should expose interoperable APIs, and if an API can only be implemented on Windows, it simply shouldn't be exposed. Note that OS X provides a list of languages that can be typed with each keyboard input source, not a single language per layout. This doesn't meaningfully map to a value that could be exposed by Event.locale, and doesn't lend itself to implementing your use case either. > > 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. We should be able to do better than provide an unreliable heuristic to address the two use cases that you gave in www-dom thread. A targeted API to educate quotes seems to be in order here. > 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. I have taken the time to read the thread, and these concerns have not been discussed there. Getting several experts who frequent a mailing list reach a consensus is an important milestone, but it's perfectly normal to have blocking feedback when it comes to implementation.

Created attachment 122132 [details] System Preferences screenshot

Hey, KeyboarEvent.key is supported by Firefox and IE (and there are works on adding it to Blink - https://code.google.com/p/chromium/issues/detail?id=263724). Also, it's been at least 3 years since this property was added to the spec. Do you plan to work on implementing it?

The KeyboardEvent.key part duplicates bug 36267.

Looks like Chrome 48 will be shipping KeyboardEvent.code and KeyboardEvent.key should follow.

Also, bug 149584 duplicates the KeyboardEvent.code part of this.

Chrome will soon drop keyIdentifier https://www.chromestatus.com/features/5316065118650368 so JS that uses keyIdentifier (because of webkit) will no longer work on Chrome, so it would be incredibly useful if webkit implemented the current standard https://w3c.github.io/uievents/#events-keyboardevents

Marking as duplicate of the bug for supporting 'key' given that: - char / locale are no longer in the spec - location is already supported. New Meta bug for API we do not support of KeyboardEvent: https://bugs.webkit.org/show_bug.cgi?id=162852 *** This bug has been marked as a duplicate of bug 36267 ***