[Bug 23910] What's the good .key value while IME is open?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23910

--- Comment #2 from Gary Kacmarcik <garykac@google.com> ---
Summarizing the bug so far
==========================

Japanese IME has KanaMode where (instead of the typical IME behavior of
multiple keys being composed into a single character - like 's' + 'i' producing
'し') each key on the keyboard is associated with a character (just like a
normal keyboard layout).

So, 'a' produces 'ち' directly, 's' -> 'と', 'd' -> 'し', and so on.  Similar to
how an Arabic keyboard layout would generate key events, except that the IME
generates them with composition events.

Firefox has code to detect this mode and generate the ASCII key (e.g., 'a', 's'
or 'd') instead of the Japanese character (e.g, 'ち', 'と' or'し'). This is to
work around bugs found on websites that would (for example) check for 'a'
keydown events - these sites would break when KanaMode is enabled since they
would be getting 'ち' instead).  This bug happens because KanaMode is not
commonly used and websites (apparently) don't test against it.


Thinking more about this
========================

(1) This is working around a bug in websites, and I'm not sure it makes sense
to require this in the spec since it adds complexity.

(2) Any website that is broken with KanaMode is also broken if the user has an
Arabic (or any other non-English) keyboard.  The fix above only handles the
specific case for a specific mode of the Japanese IME. So it doesn't seem (to
me) like the fix *really* fixes the problem - it just makes it less likely to
impact users.

(3) It sounds like the broken websites should really be using 'code' if they're
interested in knowing which physical key was pressed. (Hard to tell without
knowing more details about the broken sites.)

(4) In an ideal world, I'd prefer KanaMode to return simple key events (without
any composition events). Sadly, I don't think that's possible with the way IMEs
are setup on the various platforms (but I'm happy to be wrong here).


So, the question boils down to: Should we update the spec to allow Firefox to
continue their (partial) fix for broken websites?

Adding this exception to the spec will mean adding an awkward and potentially
confusing paragraph (or two + an example) to an already complex spec.


My sense is that we should (reluctantly) add this exception -  but only because
this is already shipping behavior (otherwise it wouldn't be worth considering).
 However, since the "fix" doesn't even really fix the problem, I'm not sure if
it's worth the effort.


Any further thoughts or comments on this issue?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 8 April 2014 01:29:50 UTC