1668134 - Add telemetry probes to know how much web apps use `beforeinput` events of Gecko

Status: RESOLVED FIXED

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

Description

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

There is no standardized way of feature detection for beforeinput event since Chromium does not support GlobalEventHandlers.onbeforeinput.

So, web apps must consider whether beforeinput is available or not with the following check:

1. InputEvent.getTargetRanges() is available
2. Whether beforeinput event listener is called or not
3. UA name
4. Something other which can distinguish whether Gecko/Firefox or not

#1 is the recommended way, e.g., typeof InputEvent.prototype.getTargetRanges === "function" because Gecko make it enabled only when beforeinput event is enabled.

#2 is also a correct way, but it makes the code complicated.

#3 and #4 are bad approach, but I guess a lot of apps do this. If so, we need to request developers to use #1 instead because not using beforeinput may cause web-compat issues and may cause the web apps running slower on Gecko.

So, perhaps, we should collect the following data:

1. Percentage of document having beforeinput event listener with having HTMLEditor (i.e., used with contenteditable or designMode).
2. Percentage of document having beforeinput event listener without HTMLEditor (i.e., used with <input> or <textarea>.
3. Percentage of document having mutation event listeners but not having beforeinput event listener with having HTMLEditor.
4. Percentage of document having mutation observers but not having beforeinput event listener with having HTMLEditor.

The #3 is the worst scenario for us. Existing mutation event listeners makes any DOM changes (both by editor and JS) much slower than the other browsers.

Honestly, I'd like to know the URLs of #3 and #4, but collecting URLs breaks users' privacy. So, we shouldn't do that.

Comment 1

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

Ah, #2 isn't required because of not bad scenario for use. Then, we can store the state in HTMLEditor rather than Document. It may help footprint.

Comment 2

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

Attachment: data collection review form v.1.0

Comment 3

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

Attachment: Bug 1668134 - part 1: Make `nsPIDOMWindowInner` have an API to know whether the window or its descendants has had `beforeinput` event listeners r=smaug!

When HTMLEditor instances are destroyed, I'd like to collect how much
instances are worked with beforeinput event listeners. Before adding such
telemetry probe, this patch adds methods to set/get whether a beforeinput
event listener has had added or not to nsPIDOMWindowInner.

Comment 4

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

Attachment: Bug 1668134 - part 2: Make `nsPIDOMWindowInner` have an API to know whether a node is (was) in the window has been observed by web apps with a mutation observer r=smaug!

There is similar API in Document, but they indicate whether a node has been
observed by any mutation receiver, not only by MutationObserver of JS.
However, I'd like to know the percentage of web apps which use
MutationObserver, but not use beforeinput events. Therefore, this patch
adds similar API into nsPIDOMWindowInner as same as beforeinput and
ignores MutationObservers which are created by chrome script and addons.

Depends on D92546

Comment 5

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

Attachment: Bug 1668134 - part 3: Add telemetry probes to collect how percentage of `HTMLEditor` is or is not handled with `beforeinput` event listeners r=smaug data-review=tdsmith

Unfortunately, there is no official way to detect whether browser supports
or not beforeinput event in the wild because Chromium does not support
onbeforeinput event handler attribute. On the other hand, we're the
last browser vendor which does not support beforeinput event, and we
make InputEvent.getTargetRanges() enabled only when beforeinput event
because it returns meaningful value only when the event type is beforeinput.
So, web apps can detect beforeinput event support with checking type of
or existence of it instead. However, in our experience, it's guessed what
a lot of web apps check whether "Firefox" or not to consider whether it
can use beforeinput events. If so, we need to announce shipping
beforeinput event and the way to feature detection before actually shipping
it. Otherwise, we wouldn't get enough feedback from testers.

First of all for shipping beforeinput events, we should collect how much
web apps which use HTMLEditor use beforeinput event when it's enabled,
and how much web apps use mutation events or mutation observer instead of
beforeinput events even when it's enabled.

Honestly, I'd like to collect URLs which don't use beforeinput event, but
use mutation events or mutation observer. But it's really sensitive data
so that I believe that we shouldn't collect it.

Depends on D92547

Comment 6

[Tim Smith (inactive) 👨‍🔬 [:tdsmith]]

Comment on attachment 9179790 [details]
data collection review form v.1.0

Thanks for the request; please request data-review from one of the stewards listed at https://wiki.mozilla.org/Firefox/Data_Collection and not directly from agray.

--

1. Is there or will there be documentation that describes the schema for the ultimate data set in a public, complete, and accurate way?

Yes, in the probe definition files and the Probe Dictionary.

2. Is there a control mechanism that allows the user to turn the data collection on and off?

Yes, the Firefox telemetry opt-out.

3. If the request is for permanent data collection, is there someone who will monitor the data over time?

n/a

4. Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Category 1, technical data.

5. Is the data collection request for default-on or default-off?

Default-on.

6. Does the instrumentation include the addition of any new identifiers (whether anonymous or otherwise; e.g., username, random IDs, etc. See the appendix for more details)?

No.

7. Is the data collection covered by the existing Firefox privacy notice?

Yes.

8. Does there need to be a check-in in the future to determine whether to renew the data?

masayuki is responsible for renewing the probe as necessary.

9. Does the data collection use a third-party collection tool?

Nope.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0aaffbe30e9e
part 1: Make `nsPIDOMWindowInner` have an API to know whether the window or its descendants has had `beforeinput` event listeners r=smaug
https://hg.mozilla.org/integration/autoland/rev/0ed6273ce9c5
part 2: Make `nsPIDOMWindowInner` have an API to know whether a node is (was) in the window has been observed by web apps with a mutation observer r=smaug
https://hg.mozilla.org/integration/autoland/rev/df6b5488f4b4
part 3: Add telemetry probes to collect how percentage of `HTMLEditor` is or is not handled with `beforeinput` event listeners r=smaug data-review=tdsmith

Comment 8

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/0aaffbe30e9e
https://hg.mozilla.org/mozilla-central/rev/0ed6273ce9c5
https://hg.mozilla.org/mozilla-central/rev/df6b5488f4b4