Intent to ship: set keyCode or charCode of "keypress" event to the other's non-zero value

[Masayuki Nakano]

Summary: We'll set keyCode of "keypress" event to its charCode value if
keyCode is 0, charCode of "keypress" event to its keyCode value if
charCode is 0.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1479964

Link to standard: "conflated model" of
https://w3c.github.io/uievents/#determine-keypress-keyCode (we've used
"split model"). But no declaration of charCode value of Enter key press.

(Oh, I had not realized this section when I wrote the commit message...)

Platform coverage: All

Estimated or target release: 65

DevTools bug: N/A

Do other browser engines implement this?

Yes, the other browsers use this behavior traditionally, and UI Events
declared this behavior as "conflated model".

web-platform-tests: N/A due to requiring user input, but we have
mochitests with synthesized events.

This new behavior was enabled in Nightly since early of 65. This caused
breaking Google Closure Library. However, it have been fixed by the
cooperation of the developers.

Of course, we may meet other broken web apps especially in intranet.
While we're testing this behavior in Nightly, we used blacklist pref
(dom.keyboardevent.keypress.hack.use_legacy_keycode_and_charcode) to
disable this new behavior only in specific domains. If we'll get broken
web apps even after release, we and users can disable it with using this
blacklist.

Enabling patch has been landed from:
https://bugzilla.mozilla.org/show_bug.cgi?id=1496288
because we need to manage those changes as a set.

[James Graham]

Post by Masayuki Nakano
web-platform-tests: N/A due to requiring user input, but we have
mochitests with synthesized events.

I think it should be possible to write web-platform-tests for this kind
of thing now, using the testdriver API and in particular the actions
support see e.g. [1], [2]

If this still doesn't meet your use case please let me know because we
should work out how to make testing this kind of stuff possible
cross-browser; as you well know UI events have been an interop nightmare
in the past and we can't afford to let that situation continue into the
future for new devices and APIs.

[1] https://web-platform-tests.org/writing-tests/testdriver.html
[2]
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/infrastructure/testdriver/actions/multiDevice.html

[Masayuki Nakano]

Post by James Graham

Post by Masayuki Nakano
web-platform-tests: N/A due to requiring user input, but we have
mochitests with synthesized events.

I think it should be possible to write web-platform-tests for this kind
of thing now, using the testdriver API and in particular the actions
support see e.g. [1], [2]
If this still doesn't meet your use case please let me know because we
should work out how to make testing this kind of stuff possible
cross-browser; as you well know UI events have been an interop nightmare
in the past and we can't afford to let that situation continue into the
future for new devices and APIs.
[1] https://web-platform-tests.org/writing-tests/testdriver.html
[2]
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/infrastructure/testdriver/actions/multiDevice.html

Thank you for the information.

I'm looking for the implementation of the keyboard event dispatchers,
but I've not found it yet. Could you let me know where it is?

FYI: Generally, for testing Gecko itself, test API should fill all
attributes of KeyboardEvent with usual value for the key unless testing
special cases. Additionally, dispatched event should be trusted event
and has widget internally, and propagated the DOM tree as actual user
input events.

It seems that synthesized events won't be initialized with our widget
nor tables in JS like synthesizeKey() in EventUtils.js. For example,
keyCode value of punctuation keys are different between
browsers/platforms/environments.

[James Graham]

Post by Masayuki Nakano

Post by James Graham

Post by Masayuki Nakano
web-platform-tests: N/A due to requiring user input, but we have
mochitests with synthesized events.

I think it should be possible to write web-platform-tests for this
kind of thing now, using the testdriver API and in particular the
actions support see e.g. [1], [2]
If this still doesn't meet your use case please let me know because we
should work out how to make testing this kind of stuff possible
cross-browser; as you well know UI events have been an interop
nightmare in the past and we can't afford to let that situation
continue into the future for new devices and APIs.
[1] https://web-platform-tests.org/writing-tests/testdriver.html
[2]
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/infrastructure/testdriver/actions/multiDevice.html

Thank you for the information.
I'm looking for the implementation of the keyboard event dispatchers,
but I've not found it yet. Could you let me know where it is?

So, the full picture is that the test harness provides a js
implementation of the testdriver API action_sequence method [1] which
routes a message to the harness asking it to dispatch some actions. In
the marionette backend this ends up at [2] which sends a
WebDriver:PerformActions command to the browser. That ends up in [3] and
then [4] and [5] which in the case of a key event goes through [6] and,
skipping several layers of setup, eventually [7]. That is ultimately
using nsITextInputProcessor, and the implementation looks extremely
similar to synthesizeKey from EventUtils.js [8].

So I believe that unless one of the intervening layers is doing
something wrong or putting unnecessary constraints on what's possible,
it should be possible to use this API to generate the exact same events
that you would get from EventUtils.js. If there are use cases you are
unable to replicate using the testdriver API please let me know because
they are likely bugs that ought to be fixed; the intent here is that the
events looks as close as possible to real key events generated by real
user interaction.

[1]
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/tools/wptrunner/wptrunner/testdriver-extra.js#75
[2]
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/tools/wptrunner/wptrunner/executors/executormarionette.py#374
[3]
https://searchfox.org/mozilla-central/source/testing/marionette/listener.js#776
[4]
https://searchfox.org/mozilla-central/source/testing/marionette/action.js#988
[5]
https://searchfox.org/mozilla-central/source/testing/marionette/action.js#1096
[6]
https://searchfox.org/mozilla-central/source/testing/marionette/action.js#1142
[7]
https://searchfox.org/mozilla-central/source/testing/marionette/event.js#384
[8]
https://searchfox.org/mozilla-central/source/testing/mochitest/tests/SimpleTest/EventUtils.js#850