Re: Intent to ship: stop dispatching "keypress" events when pressed key (key combination) does not introduce text input
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
Re: Intent to ship: stop dispatching "keypress" events when pressed key (key combination) does not introduce text input
On Thursday, November 29, 2018 at 5:22:47 PM UTC-8, masayuki nakano wrote: > Summary: We'll stop dispatching non-printable "keypress" events. > "non-printable" means that key press or key combination does not > introduce text input without IME. For example, arrow key press, Ctrl+A, > etc. > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=968056 > > Link to standard: > For keys which introduce text input: > https://w3c.github.io/uievents/#legacy-keyboardevent-event-types > For Enter key: > https://github.com/w3c/uievents/issues/183 > > 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 the behavior as "standard". > > 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 61. This caused breaking > a lot of major web apps. However, all of them have been fixed by the > cooperation of the vendors. > > 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.dispatch_non_printable_keys) 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. > > -- > Masayuki Nakano > Software Engineer, Mozilla 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. ___ 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
On Thursday, November 29, 2018 at 5:22:47 PM UTC-8, masayuki nakano wrote: > Summary: We'll stop dispatching non-printable "keypress" events. > "non-printable" means that key press or key combination does not > introduce text input without IME. For example, arrow key press, Ctrl+A, > etc. > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=968056 > > Link to standard: > For keys which introduce text input: > https://w3c.github.io/uievents/#legacy-keyboardevent-event-types > For Enter key: > https://github.com/w3c/uievents/issues/183 > > 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 the behavior as "standard". > > 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 61. This caused breaking > a lot of major web apps. However, all of them have been fixed by the > cooperation of the vendors. > > 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.dispatch_non_printable_keys) 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. > > -- > Masayuki Nakano > Software Engineer, Mozilla 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 the the "input" event is for. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: stop dispatching "keypress" events when pressed key (key combination) does not introduce text input
Summary: We'll stop dispatching non-printable "keypress" events. "non-printable" means that key press or key combination does not introduce text input without IME. For example, arrow key press, Ctrl+A, etc. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=968056 Link to standard: For keys which introduce text input: https://w3c.github.io/uievents/#legacy-keyboardevent-event-types For Enter key: https://github.com/w3c/uievents/issues/183 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 the behavior as "standard". 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 61. This caused breaking a lot of major web apps. However, all of them have been fixed by the cooperation of the vendors. 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.dispatch_non_printable_keys) 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. -- Masayuki Nakano Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
