1496288 - Ship Window.event, keyCode change, and keypress event handling changes

Status: RESOLVED FIXED

(Core :: DOM: Events, defect, P2)

Description

[Brian Birtles (:birtles, Feb 26~ parental leave)]

These changes seem to be interconnected:

* Window.event (bug 218415, preffed off in release in bug 1493869)
* keypress events for non-printable keys (bug 1440189, bug 968056 tracks shipping)
* Changes to event.keyCode (bug 1479964)

That is, some content seems to assume they are a set (i.e. if window.event is present, then assume keyCode and keypress function in a certain way).

It's quite a tricky set of changes so the proposal is to try turning them on in early beta in the 64 cycle.

Comment 1

[Dan]

Is it active in Nightly already?

Comment 2

[Brian Birtles (:birtles, Feb 26~ parental leave)]

I believe the first two are but the third: keyCode changes (bug 1479964) has yet to land.

Comment 3

[Dan]

Thanks!

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

bug 354358 should ride the train too when bug 968056 does so (for reducing number of times to update web apps for keyboard event changes of Gecko).

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Now, it's safe to release strict keypress dispatching (bug 968056) and dispatching keydown/keyup events during composition (bug 
354358). Mirroring non-zero keyCode/charCode of keypress events (bug 1479964) requires verification with Google Docs and reply from rememberthemilk.com.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a4fc18afd1016efd108c60d4bea4024b76cd2dca

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 1496288 - part 1: Make blacklist prefs for keypress event behavior changes ride the train

Basically, we shouldn't have blacklist to disable web API.  However, the
keypress event behavior changes are not standardized things.  Therefore,
if some web developers realize that they need to change their apps when
it's too late for them, Firefox users need to use another browser for
such web apps for several weeks or more, and such things may make the users
switch their default browser.  For avoiding such worst scenario, we should
take the blacklists and if we get such compatibility reports, we should
add the domains into the blacklist even in release channel.

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 1496288 - part 2: Stop dispatching non-printable "keypress" events, set keyCode or charCode value to the other value when it's zero, start to dispatch "keydown" and "keyup" events during composition, and enable window.event by default

First one is for bug 968056.  UI Events declares that "keypress" events should
be dispatched only when a key press produces one or more characters (and also
discussing about Enter key press for backward compatibility).  Therefore, we
should stop dispatching "keypress" events for non-printable keys (like arrow keys,
Ctrl + A, etc) in the default group on content for conforming to UI Events, but
keep dispatching them in chrome and in the system group on content.

Next one is for bug 1479964.  No spec declares that what value should be set
to keyCode and charCode value of "keypress" events because declaring that would
break existing web apps which handle them with UA string.  However, some web
apps assume that if window.event is available, keyCode value of "keypress" event
is set to a Unicode code point of inputting character.  We set only charCode
to it, but the other browsers sets both keyCode and charCode to a Unicode
code point of inputting character.  Therefore, we need to follow the other
browsers' behavior for this because changing value from zero to non-zero is
safer than non-zero to non-zero or zero.

And also next one is for bug 354358.  UI Events declares that "keydown" and
"keyup" events represent physical key state and should be fired even during
composition.  As far as the reported issues, this behavior is expected mainly
by Korean web developers and some web apps depend on the behavior.  Therefore,
we need to start to dispatch them during composition.

Finally, for bug 218415, we should enable window.event.  This is declared by
the Living DOM Standard.  A lot of web apps depend on window.event and the
last blocker, bug 1479964 was fixed so that it is the time to enable this.

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I'm not sure whether we should enable window.event in this bug because I don't handle it. However, in the discussion with emails, it seems that we can do it here. If you think that I shouldn't do it, let me know.  Then, I'll remove the window.event part from the last patch.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f854c2a5429c
part 1: Make blacklist prefs for keypress event behavior changes ride the train r=smaug
https://hg.mozilla.org/integration/autoland/rev/2f92fd614d56
part 2: Stop dispatching non-printable "keypress" events, set keyCode or charCode value to the other value when it's zero, start to dispatch "keydown" and "keyup" events during composition, and enable window.event by default r=smaug

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

https://groups.google.com/forum/#!topic/mozilla.dev.platform/DrYa0gDxI5Q
https://groups.google.com/forum/#!topic/mozilla.dev.platform/E8DyIJBhu1g
https://groups.google.com/forum/#!topic/mozilla.dev.platform/IWLLJmoGroA
https://groups.google.com/forum/#!topic/mozilla.dev.platform/riVG9FqN9iM

Comment 12

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/f854c2a5429c
https://hg.mozilla.org/mozilla-central/rev/2f92fd614d56

Comment 13

[Chris Mills [:cmills]]

I'm trying to work out what to say in the docs about these changes. This is all rather confusing ;-)

This is what I think has happened:

1. window.event has been enabled again

2. keypress event handling has changed like so:

a. Non-printable keys (like cursor keys) no longer dispatch keypress events
b. keydown and keyup events are now dispatched during composition

3. keyCode changes - "set keyCode or charCode to the other value when it's zero". Ummm, I didn't really understand this one. Can you expand on this?

And is this all available in release?

Comment 14

[Dan]

Are "keyup" and "keydown" essentially the same as "keyReleased" and "keyPressed" ?

Comment 15

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #13)
> 1. window.event has been enabled again

Yes.

> 2. keypress event handling has changed like so:
> 
> a. Non-printable keys (like cursor keys) no longer dispatch keypress events

Yes.

> b. keydown and keyup events are now dispatched during composition

Yes.

> 3. keyCode changes - "set keyCode or charCode to the other value when it's
> zero". Ummm, I didn't really understand this one. Can you expand on this?

Previously, one of charCode or keyCode of "keypress" event was set to 0. With the change, if it's Enter key press, charCode is set to its keyCode, 13, and otherwise, its keyCode is set to its charCode value. For example, if you press "." key, "keypress" event was { keyCode: 0, charCode: 0x2E }, but it's now { keyCode: 0x2E, charCode: 0x2E } even though keyCode 0x2E means "Delete" key if the event type is "keydown" or "keyup".

> And is this all available in release?

Yes.

Comment 16

[Dan]

What about my question?

Comment 17

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Daniel from comment #16)
> What about my question?

I don't understand, what are you talking about?

Comment 18

[Mike Taylor [:miketaylr]]

(In reply to Daniel from comment #14)
> Are "keyup" and "keydown" essentially the same as "keyReleased" and
> "keyPressed" ?

I'm not sure what keyReleased or keyPressed are (maybe a java thing?), but you can find keyup and keydown in the UI events spec: https://w3c.github.io/uievents/#events-keyboard-types

Comment 19

[Dan]

Yes, thank you for the link, those variable names (that I thought of, keyReleased, keyDown) is just what I thought it was, as per https://w3c.github.io/uievents/#keydown, where it says "A user agent MUST dispatch this event when a key is pressed down." and per https://w3c.github.io/uievents/#keyup , "A user agent MUST dispatch this event when a key is released.". All clear now, thanks for the help, Mike.

Comment 20

[Kohei Yoshino [:kohei]]

Posted site compatibility note: https://www.fxsitecompat.com/en-CA/docs/2018/support-for-window-event-and-event-returnvalue-has-been-added-again/

Comment 21

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e7e55953f8443929387711f7a02d816fca166c46

Comment 22

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3115e4ad39c5937b0321fd21dde6525545412c84

Comment 23

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=fa06af4e1678062c4e5eb334bf4ae53ca4d8dd4c

Comment 24

[Chris Mills [:cmills]]

OK, I think I have documented this adequately.

See the additions to the Fx65 rel notes:
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/65#APIs

For the event/returnValue re-additions, I've updated the compat data:
https://github.com/mdn/browser-compat-data/pull/3357

For the charCode/keyCode mirroring behavior, I've aded notes to these places:

https://developer.mozilla.org/en-US/docs/Web/Events/keypress#Browser_compatibility
https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onkeypress#Browser_compatibility_notes
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent#Compatibility_notes

For "Non-printable keys (like cursor keys) no longer dispatch keypress events", this was covered by https://bugzilla.mozilla.org/show_bug.cgi?id=968056#c29

For "keydown and keyup events are now dispatched during composition", this was covered by https://bugzilla.mozilla.org/show_bug.cgi?id=354358#c55

Let me know if this covers it, or if you'd like to see anything else. Thanks!

Comment 25

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #24)

OK, I think I have documented this adequately.

See the additions to the Fx65 rel notes:
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/65#APIs

Ah, really sorry. Window.event, Event.returnValue and using same value to keyCode and charCode of keypress events were put off to 66. See bug 1520756.

For the event/returnValue re-additions, I've updated the compat data:
https://github.com/mdn/browser-compat-data/pull/3357

So, should be update it 66 again (but we're still not sure we can ship them at 66 as we planned).

For the charCode/keyCode mirroring behavior, I've aded notes to these places:

https://developer.mozilla.org/en-US/docs/Web/Events/keypress#Browser_compatibility

So, should update "As of Firefox 65". (Note that non-printable keypress dispatching and keydown/keyup event dispatching in composition are shipped in 65.)

And note that I found technical term of the behaviors in UI Events spec. Our traditional behavior is called as "split model". The new behavior is called as "conflated model". You can introduce these terms.
https://w3c.github.io/uievents/#determine-keypress-keyCode

https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onkeypress#Browser_compatibility_notes

Same above, you should update "As of Firefox 65" only in the first paragraph.

https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent#Compatibility_notes

Ditto.

For "Non-printable keys (like cursor keys) no longer dispatch keypress events", this was covered by https://bugzilla.mozilla.org/show_bug.cgi?id=968056#c29

Thanks!

For "keydown and keyup events are now dispatched during composition", this was covered by https://bugzilla.mozilla.org/show_bug.cgi?id=354358#c55

Thanks!

Comment 26

[Chris Mills [:cmills]]

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #25)

(In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #24)

OK, I think I have documented this adequately.

See the additions to the Fx65 rel notes:
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/65#APIs

Ah, really sorry. Window.event, Event.returnValue and using same value to keyCode and charCode of keypress events were put off to 66. See bug 1520756.

Hehe. This really is the "gift that keeps on giving", as we say in the UK ;-)

No matter, I'm happy to make the changes to get this right. I've moved those notes out of the 65 rel notes, and in to the 66 rel notes for now:

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/66#APIs

You'll see that I've put a "Tentative" note on them, to make it clear they are not assured for 66. But I still want to keep these notes recorded somewhere because they will be useful on they finally ship.

For the event/returnValue re-additions, I've updated the compat data:
https://github.com/mdn/browser-compat-data/pull/3357

So, should be update it 66 again (but we're still not sure we can ship them at 66 as we planned).

For the moment, since they are not assured to ship in 66, I've just updated the PR to put them back to being not shipped/disabled, plus I've added notes to explain the situation. I hope that's OK. We can always update it again when it finally ships.

For the charCode/keyCode mirroring behavior, I've aded notes to these places:

https://developer.mozilla.org/en-US/docs/Web/Events/keypress#Browser_compatibility

So, should update "As of Firefox 65". (Note that non-printable keypress dispatching and keydown/keyup event dispatching in composition are shipped in 65.)

And note that I found technical term of the behaviors in UI Events spec. Our traditional behavior is called as "split model". The new behavior is called as "conflated model". You can introduce these terms.
https://w3c.github.io/uievents/#determine-keypress-keyCode

I've added a mention of this to the note in the 66 rel notes, as it is a useful detail.

https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onkeypress#Browser_compatibility_notes

Same above, you should update "As of Firefox 65" only in the first paragraph.

https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent#Compatibility_notes

Ditto.

So, for these last three, I've just removed the note altogether for now, since it is not currently shipped. I hope that's OK.

For "Non-printable keys (like cursor keys) no longer dispatch keypress events", this was covered by https://bugzilla.mozilla.org/show_bug.cgi?id=968056#c29

Thanks!

For "keydown and keyup events are now dispatched during composition", this was covered by https://bugzilla.mozilla.org/show_bug.cgi?id=354358#c55

Thanks!

Thanks to you too for all the help on this. It has taken a while, but I'm starting to understand it.

Comment 27

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #26)

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #25)
No matter, I'm happy to make the changes to get this right. I've moved those notes out of the 65 rel notes, and in to the 66 rel notes for now:

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/66#APIs

Thanks!

For the event/returnValue re-additions, I've updated the compat data:
https://github.com/mdn/browser-compat-data/pull/3357

So, should be update it 66 again (but we're still not sure we can ship them at 66 as we planned).

For the moment, since they are not assured to ship in 66, I've just updated the PR to put them back to being not shipped/disabled, plus I've added notes to explain the situation. I hope that's OK. We can always update it again when it finally ships.

Sure.

https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onkeypress#Browser_compatibility_notes

Same above, you should update "As of Firefox 65" only in the first paragraph.

https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent#Compatibility_notes

Ditto.

So, for these last three, I've just removed the note altogether for now, since it is not currently shipped. I hope that's OK.

Thanks.