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

[Masayuki Nakano]

On 2018/11/30 20:42, James Graham wrote:

On 30/11/2018 01:37, Masayuki Nakano wrote:
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.


--
Masayuki Nakano 
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: stop dispatching "keypress" events when pressed key (key combination) does not introduce text input

[Masayuki Nakano]

On 2018/12/01 8:51, Eli Grey via dev-platform wrote:

I think the spec is confusing and not well-reasoned enough to introduce this 
misnomer. This change will make it so that there are two events with synonymous 
meaning, and only introduces potential site breakage.

The event is literally called "keypress", not "input". Developers are going to end up 
using it to track keypresses regardlessly due to the incorrect name. If they want to track input, that's what 
the "input" event is for.


"keypress" event was introduced by IE, and UI Events (formerly, called 
DOM Level 3 Events) defines the behavior from existing browsers, but 
marking them as "legacy".


Under current spec, "keydown" and "keyup" events represent "physical" 
event on the input device. "keypress" is "logical" event of text input 
from keyboard directly (i.e., not via IME). "input" and "beforeinput" 
are similar to "keypress", but they are fired only when an editor has 
focus and with any input devices/middle wares.


Currently, I'm working on implementing "beforeinput".  It allows all web 
apps to stop handling "keypress" in the future and to prevent default 
action easier.


--
Masayuki Nakano 
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform