This is blocker issue of enabling window.event [*1].
When we enable window.event, a lot of web sites are broken like this code:
> foo.addEventListener("keypress", function (event) {
> var charCode;
> if (window.event) {
> charCode = event.keyCode;
> } else {
> charCode = event.which;
> }
> // do something with |charCode|...
> });
window.event was introduced by Internet Explorer, and IE sets charCode
value to keyCode and which. Chrome follows this behavior.
On the other hand, Gecko has kept taking traditional style of ours. That
is, when pressing key causes inputting a character, sets charCode and
which to the Unicode code point of the character, and sets keyCode to 0.
Otherwise, i.e., does not cause inputting a character, sets keyCode and
which to keyCode value of the key, and sets charCode to 0.
So, enabling window.event causes we start to use path for IE even though
our keyCode/charCode values of keypress events are different from IE's.
Therefore, we started to use the IE style in Nightly at bug 1479964
[*2]. (I'm really sorry, I forgot to email to dev-platform at this time.)
However, that causes breaking Google Closure and web apps which use
Google Closure. Therefore, I disabled it with turning off the pref [*3].
Now, the new behavior will be re-enabled in Nightly by default again,
but with blacklist (currently, Google Docs and Remember The Milk are in
it) [*4].
If you find new regression about key operation in some web apps, please
file a bug for each web app, and block bug 1479964.
1: https://bugzilla.mozilla.org/show_bug.cgi?id=218415
2: https://bugzilla.mozilla.org/show_bug.cgi?id=1479964
3: https://bugzilla.mozilla.org/show_bug.cgi?id=1497546
4: https://bugzilla.mozilla.org/show_bug.cgi?id=1502795
--
Masayuki Nakano <masay...@d-toybox.com>
Software Engineer, Mozilla
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
