Intent to ship: beforeinput event and InputEvent.getTargetRanges()

[Masayuki Nakano]

Since Nov. 2020, we enabled them by default in Nightly channel and early
beta channel [1].

According to the telemetry [2], `beforeinput` events have not been used
by most web apps which uses `designMode` or `contenteditable` (only
1.53%, 3k instances of `HTMLEditor`), but we know that this makes each
framework and rich text editor app needs to work a lot for Firefox. So,
not supporting this may cause new rich text editor apps not supporting
Firefox. Therefore, we should ship this as soon as possible.

Even though after shipping it in the Nightly channel, we've not gotten
bug reports about compatibility with the other browsers. This may not
mean our implementation is enough compatible with the other browsers,
but anyway, there is no reasonable reason to wait more feedback from web
developers. Therefore, I believe that it is a time to ship it in the
release channel.

Currently, our behavior is similar to Blink which conforms to Input
Events Level 1 [3], but different from WebKit which conforms to Input
Events Level 2 [4] partially. There are 2 reasons for taking the Level
1. One is that the compatibility with Blink, it is really important due
to their market share. The other is that there are some backward
compatibility issues in Level 2 [5][6].

On the other hand, web apps cannot manage input from IME only with
`beforeinput` of Level 1. Therefore, I filed a spec issue to port a part
of Level 2 to Level 1 [7], and it's discussed in another spec issue too
[8]. The spec change is now agreed, but I'm not sure when it's fixed,
when Blink conforms to the new Level 1. Therefore, we probably ship
`beforeinput` aligned to current Blink (this is the default behavior in
Nightly channel). And then, we should change the behavior to conform to
new Level 1, when Blink updates its behavior. Even though changing
behavior is risky after shipping it.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1665530
Standard: [3] and [4]
Platform coverage: All
Preference: dom.input_events.beforeinput.enabled
DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1607686 (FIXED)
Other browsers: Gecko is the last one not supporting `beforeinput`
web-platform-tests: Not enough due to requiring TestDeiver (other
browsers implemented this before it's availble) and/or depends on
browser specific behavior, etc. But I added some tests when I worked on
implementing `getTargetRanges()` [9][10].

[1] https://groups.google.com/g/mozilla.dev.platform/c/LCTfPNZMWKU
[2] https://mzl.la/2M3bTYh
[3] https://rawgit.com/w3c/input-events/v1/index.html
[4] https://w3c.github.io/input-events/
[5] https://github.com/w3c/input-events/issues/86
[6] https://github.com/w3c/input-events/issues/115#issuecomment-761277004
[7] https://github.com/w3c/input-events/issues/115
[8] https://github.com/w3c/editing/issues/275
[9]
https://searchfox.org/mozilla-central/search?q=%22beforeinput%22&path=web-platform%2Ftests%2F&case=false&regexp=false
[10]
https://searchfox.org/mozilla-central/search?q=input-events-get-target-ranges.js&path=web-platform%2Ftests%2F&case=false&regexp=false

--
Masayuki Nakano <masa...@d-toybox.com>
Working on DOM, Events, editor and IME handling for Gecko

[Anne van Kesteren]

On Fri, Jan 29, 2021 at 3:07 AM Masayuki Nakano <masa...@d-toybox.com> wrote:
> Therefore, we probably ship
> `beforeinput` aligned to current Blink (this is the default behavior in
> Nightly channel). And then, we should change the behavior to conform to
> new Level 1, when Blink updates its behavior. Even though changing
> behavior is risky after shipping it.

Thank you for this detailed description of the situation Masayuki!
This seems like the right decision to me given the rather messy state
of the specification and other implementations, as well as not having
insight into when those other implementations might or might not be
updated.