1506537 - Measure keypress to presentation input latency

Status: RESOLVED FIXED

(Core :: Performance, enhancement)

Description

[Bas Schouten (:bas.schouten)]

We should track telemetry of how long it typically takes a keypress to appear on the screen after receiving it.

Comment 1

[Bas Schouten (:bas.schouten)]

Attachment: Part 1: Register KeyPress events with the LayerManager when painting is scheduled

Comment 2

[Bas Schouten (:bas.schouten)]

Attachment: Part 2: Add telemetry for keypress presentation latency

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

aha, need to read bug 1501442 first.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

For telemetry, I believe you should follow https://wiki.mozilla.org/Firefox/Data_Collection .
Just a review isn't enough.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 9024484 [details] [diff] [review]
Part 1: Register KeyPress events with the LayerManager when painting is scheduled

> 
>+        if (aEvent->mMessage == eKeyPress) {
To make this collect only user initiated keypress, add perhaps' && aEvent->IsTrusted()'

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 9024487 [details] [diff] [review]
Part 2: Add telemetry for keypress presentation latency

Is this patch missing some part? I don't see anything to actually 
trigger KEYPRESS_PRESENT_LATENCY probe. And I don't see that in bug 1501442 either.

Comment 7

[Bas Schouten (:bas.schouten)]

Attachment: Part 2: Add telemetry for keypress presentation latency v2

Indeed I forgot to qref :-). FWIW, the guide seemed to say to feedback? someone and then I'd be asked to fill in a form.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 9024713 [details] [diff] [review]
Part 2: Add telemetry for keypress presentation latency v2

># HG changeset patch
># User Bas Schouten <[e-mail]>
># Parent  20b2b9d8dfe1827f188ab04187c2cbccae610747
>
>diff --git a/gfx/layers/Layers.cpp b/gfx/layers/Layers.cpp
>--- a/gfx/layers/Layers.cpp
>+++ b/gfx/layers/Layers.cpp
>@@ -183,16 +183,20 @@ LayerManager::RemoveUserData(void* aKey)
> void
> LayerManager::PayloadPresented()
> {
>   if (mPayload.Length()) {
>     TimeStamp presented = TimeStamp::Now();
>     for (CompositionPayload& payload : mPayload) {
>       nsPrintfCString marker("Payload Presented, type: %d latency: %dms\n", int32_t(payload.mType), int32_t((presented - payload.mTimeStamp).ToMilliseconds()));
>       profiler_add_marker(marker.get());
(not about this bug, but could we do the nsPrintfCString stuff only when profiler is running? I'd rather not add useless allocation/deallocation. I guess profiler_is_active() should work.)


>+  "KEYPRESS_PRESENT_LATENCY": {
>+    "record_in_processes": [ "main", "gpu" ],
>+    "alert_emails": [ "[e-mail]" ],
>+    "expires_in_version": "never",
>+    "kind": "exponential",
>+    "low": 10,
Could low be a bit smaller? Why not even 1. Changes in main event loop handling could easily affect only couple of ms, yet it would be nice to see them

Comment 9

[Bas Schouten (:bas.schouten)]

(In reply to Olli Pettay [:smaug] (high review load) from comment #8)
> Comment on attachment 9024713 [details] [diff] [review]
> Part 2: Add telemetry for keypress presentation latency v2
> 
> ># HG changeset patch
> ># User Bas Schouten <[e-mail]>
> ># Parent  20b2b9d8dfe1827f188ab04187c2cbccae610747
> >
> >diff --git a/gfx/layers/Layers.cpp b/gfx/layers/Layers.cpp
> >--- a/gfx/layers/Layers.cpp
> >+++ b/gfx/layers/Layers.cpp
> >@@ -183,16 +183,20 @@ LayerManager::RemoveUserData(void* aKey)

> >+  "KEYPRESS_PRESENT_LATENCY": {
> >+    "record_in_processes": [ "main", "gpu" ],
> >+    "alert_emails": [ "[e-mail]" ],
> >+    "expires_in_version": "never",
> >+    "kind": "exponential",
> >+    "low": 10,
> Could low be a bit smaller? Why not even 1. Changes in main event loop
> handling could easily affect only couple of ms, yet it would be nice to see
> them

As far as I can tell, a keypress can never be composited within less than 16.67ms right? Or am I missing something obvious here.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

If refresh driver is ticking, there might be vsync right after keypress has been handled, then data is sent to compositor... ok, I guess compositor takes 16ms.

Comment 11

[Bas Schouten (:bas.schouten)]

(In reply to Olli Pettay [:smaug] (high review load) from comment #10)
> If refresh driver is ticking, there might be vsync right after keypress has
> been handled, then data is sent to compositor... ok, I guess compositor
> takes 16ms.

Right, that's what I meant, we have a vsync right away, so let's say the transaction gets sent to the compositer rightaway, the compositor will then still only composite that transaction on the -next- vsync. I think.

Comment 12

[Markus Stange [:mstange]]

That's right.

But I think everyone agrees that we want to reduce that latency as much as we can, so I think we should anticipate the possibility of lower values here ahead of time, so that we don't need to change the way this value is measured in the future.

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

Yeah, and even now, what if child process sends data right before compositor is about to process the data. Can it use the new data?

Comment 14

[Bas Schouten (:bas.schouten)]

(In reply to Olli Pettay [:smaug] (high review load) from comment #13)
> Yeah, and even now, what if child process sends data right before compositor
> is about to process the data. Can it use the new data?

No, the transaction will occur on one vsync tick, and then the compositor tree will be updated, and the -subsequent- vsync tick it will call present and report presentation. But Markus' comment has already convinced me :-).

Comment 15

[Markus Stange [:mstange]]

No I think Olli is right: transactions don't wait on vsync. Transactions are processed as soon as the compositor thread is available, and then they schedule the actual composition for the next vsync. The scenario in comment 13 can happen.

Comment 16

[Chenxia Liu [:liuche]]

Comment on attachment 9024713 [details] [diff] [review]
Part 2: Add telemetry for keypress presentation latency v2

Review of attachment 9024713 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry for the delay, Bas - there were some fires last week and I didn't get to this.

Some feedback inline. As part of the data review process, can you fill out this data request form and include answers here in this comment?
https://github.com/mozilla/data-review/blob/master/request.md

::: toolkit/components/telemetry/Histograms.json
@@ +1371,5 @@
>      "bug_numbers": [1359833]
>    },
> +  "KEYPRESS_PRESENT_LATENCY": {
> +    "record_in_processes": [ "main", "gpu" ],
> +    "alert_emails": [ "[e-mail]" ],

This field allows a list - could you add an individual's email in here too? That way it's easier for people to reach out to an individual if they need to know something about this specific probe.

@@ +1372,5 @@
>    },
> +  "KEYPRESS_PRESENT_LATENCY": {
> +    "record_in_processes": [ "main", "gpu" ],
> +    "alert_emails": [ "[e-mail]" ],
> +    "expires_in_version": "never",

What is the reason for having a "never" expiration?

Generally, we don't want to add a probe and then leave it in forever, because it goes against the Mozilla data policy of "minimal and necessary data collection". Can you include a compelling reason for making this "never"? Not wanting to bump expiration is not a strong enough reason.

Comment 17

[Bas Schouten (:bas.schouten)]

    What questions will you answer with this data?

This will measure time between the first moment we measure keyboard input and the time we composite the expected 'reply' onto the screen. i.e. the time it takes for a user to see the result of their keystroke.

    Why does Mozilla need to answer these questions? Are there benefits for users? Do we need this information to address product or business requirements? Some example responses:

This tells us how readily users see the result of their keypress. Which is a key petric.

    What alternative methods did you consider to answer these questions? Why were they not sufficient?

As best we know there are no alternative methods.

    Can current instrumentation answer these questions?

No, current instrumentation does not bridge the client-host gap for the content-carent process.

    List all proposed measurements and indicate the category of data collection for each measurement, using the Firefox data collection categories on the Mozilla wiki.

This is 'interaction data'.

    How long will this data be collected? Choose one of the following:

This is something we want to record permanently.

    What populations will you measure?

We believe this should be measured amongst all channels and all populations.

    Any other filters? Please describe in detail below.

None.

    If this data collection is default on, what is the opt-out mechanism for users?

I believe this should only be opted out if the user opts out to any telemetry gathering, there is nothing remotely identifiable or privacy sensitive in this data as far as I can tell.

    Please provide a general description of how you will analyze this data.

This data will tell us something about the fundamental performance characteristics of firefox. When the user engages in an interaction (i.e. presses a key on the keyboard), how long it would take firefox to display the result of that interaction onto the screen. We believe this should be monitored continuously and is a key indicator of how responsive firefox feels to the end user.

    Where do you intend to share the results of your analysis?

I believe we should share this as soon as we get data. This is very important as far as I can tell and based on what the product team has indicated.

Comment 18

[Bas Schouten (:bas.schouten)]

(In reply to Chenxia Liu [:liuche] from comment #16)
> Comment on attachment 9024713 [details] [diff] [review]
> Part 2: Add telemetry for keypress presentation latency v2
> 
> Review of attachment 9024713 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Sorry for the delay, Bas - there were some fires last week and I didn't get
> to this.
> 
> Some feedback inline. As part of the data review process, can you fill out
> this data request form and include answers here in this comment?
> https://github.com/mozilla/data-review/blob/master/request.md
> 
> ::: toolkit/components/telemetry/Histograms.json
> @@ +1371,5 @@
> >      "bug_numbers": [1359833]
> >    },
> > +  "KEYPRESS_PRESENT_LATENCY": {
> > +    "record_in_processes": [ "main", "gpu" ],
> > +    "alert_emails": [ "[e-mail]" ],
> 
> This field allows a list - could you add an individual's email in here too?
> That way it's easier for people to reach out to an individual if they need
> to know something about this specific probe.

If we add an individual it should probably be someone who bears high level responsibility for general 'firefox responsiveness'. Vicky, would you want to be in here or do you have other suggestions?

> @@ +1372,5 @@
> >    },
> > +  "KEYPRESS_PRESENT_LATENCY": {
> > +    "record_in_processes": [ "main", "gpu" ],
> > +    "alert_emails": [ "[e-mail]" ],
> > +    "expires_in_version": "never",
> 
> What is the reason for having a "never" expiration?
> 
> Generally, we don't want to add a probe and then leave it in forever,
> because it goes against the Mozilla data policy of "minimal and necessary
> data collection". Can you include a compelling reason for making this
> "never"? Not wanting to bump expiration is not a strong enough reason.


See the form reply.

Comment 19

[Chenxia Liu [:liuche]]

> > What is the reason for having a "never" expiration?
> > 
> > Generally, we don't want to add a probe and then leave it in forever,
> > because it goes against the Mozilla data policy of "minimal and necessary
> > data collection". Can you include a compelling reason for making this
> > "never"? Not wanting to bump expiration is not a strong enough reason.
> 
> 
> See the form reply.

From this bug and discussions with :bas, I don't see a strong reason for expiration of this probe to be "never".

From the Data Collection guidelines, we generally enforce expiration in order to regularly check the following:
- To ensure that it is still necessary and useful to collect a piece of data.
- To re-identify who is responsible for the collection, monitoring, and reporting of collected data.

Vicky, Stuart - I'd suggest that this probe be set to expire in 69, which gives 6mo of data before renewing the probe, which is standard for data review policies.

https://wiki.mozilla.org/Firefox/Data_Collection

Comment 20

[Vicky Chin [:vchin]]

(In reply to Bas Schouten (:bas.schouten) from comment #18)
> (In reply to Chenxia Liu [:liuche] from comment #16)
> > Comment on attachment 9024713 [details] [diff] [review]
> > Part 2: Add telemetry for keypress presentation latency v2
> > 
> > Review of attachment 9024713 [details] [diff] [review]:
> > -----------------------------------------------------------------
> > 
> > Sorry for the delay, Bas - there were some fires last week and I didn't get
> > to this.
> > 
> > Some feedback inline. As part of the data review process, can you fill out
> > this data request form and include answers here in this comment?
> > https://github.com/mozilla/data-review/blob/master/request.md
> > 
> > ::: toolkit/components/telemetry/Histograms.json
> > @@ +1371,5 @@
> > >      "bug_numbers": [1359833]
> > >    },
> > > +  "KEYPRESS_PRESENT_LATENCY": {
> > > +    "record_in_processes": [ "main", "gpu" ],
> > > +    "alert_emails": [ "[e-mail]" ],
> > 
> > This field allows a list - could you add an individual's email in here too?
> > That way it's easier for people to reach out to an individual if they need
> > to know something about this specific probe.
> 
> If we add an individual it should probably be someone who bears high level
> responsibility for general 'firefox responsiveness'. Vicky, would you want
> to be in here or do you have other suggestions?
> 
> > @@ +1372,5 @@
> > >    },
> > > +  "KEYPRESS_PRESENT_LATENCY": {
> > > +    "record_in_processes": [ "main", "gpu" ],
> > > +    "alert_emails": [ "[e-mail]" ],
> > > +    "expires_in_version": "never",
> > 
> > What is the reason for having a "never" expiration?
> > 
> > Generally, we don't want to add a probe and then leave it in forever,
> > because it goes against the Mozilla data policy of "minimal and necessary
> > data collection". Can you include a compelling reason for making this
> > "never"? Not wanting to bump expiration is not a strong enough reason.
> 
> 
> See the form reply.

I can be on the alert_emails list.

:liuche the never expiration is because this probe is considered a Tier 1 Performance Probe. We want to be able to monitor responsiveness of Firefox over time, keypress latency being one of them. Having this probe expire at 69 will likely lead to a gap in data. We saw this with previous performance probes resulting in missing data for several releases as probe owners left/switched roles. Subsequently, we decided to set all Tier 1 probes to never expire.

Comment 21

[Stuart Philp :sphilp]

To add to Vicky's comment. We are establishing ownership and the importance of individual performance probes such that Tier 1 probes are distinctly important product metrics, and are collectively owned (directly by product, but indirectly by the broader perf team). Tier 1 probes are fundamental to the product, and are not things we are likely to change year over year. The lower level of probes (tier 3 mostly, but perhaps some of tier 2) are things that may follow the usual expiry process. We are building out the concept of the tiered system now and will share that soon so it's more explicit, but the short version is we would expect all Tier 1 probes to be active at all times.

Comment 22

[Chenxia Liu [:liuche]]

Okay, I talked briefly to :chutten and he pointed me to the googledoc of these probes (which I had never seen or heard of before). I think we can handle the probe for this specific case right now, but related to the larger Tier system for perf telemetry, I have a few questions and comments:

- Can you make public the criteria/documentation related to what "qualifies" as a Tier 1 telemetry probe?
- Currently in the doc, it looks like the criteria for Tier 1 is
> Critical for Firefox (should be tracked closely, and should not expire)
:chutten said this is missing "Firefox performance" (rather than just Firefox), so just wanted to clarify
- To the above point, I agree that this is important so we can make sure we have continuous telemetry for key metrics and performance, so I'd like to figure out some way we can do that while still maintaining a high standard for data collection policies (and not slipping into a state where no probes ever expire because it's easier to set expiration to "never"). One thing we can do (and this relates to your email to fx-datastewards) is come up with some kind of expedited review process that includes specific criteria and questions that demonstrate that a probe should in fact be considered Tier 1, rather than a renewable Tier 2 or 3. I'll send an invite to have this discussion.

As for this specific bug:
- Vicky has said she can be the permanent monitor for this, and as Firefox Perf PM, so that sounds fine
- For non-expiring probes, we usually require an automated test, because it's not undergoing verification or review every 6mo. :bas, can you add a test for this probe/feature? Telemetry JS APIs provide the ability to snapshot the current state (Telemetry.getScalarSnapshots, Telemetry.getHistogramById().snapshot(),...). So a test that clears the Telemetry state, run the code, then verifies the correct value was recorded by Telemetry.

Comment 23

[Bas Schouten (:bas.schouten)]

(In reply to Chenxia Liu [:liuche] from comment #22)
> 
> As for this specific bug:
> - Vicky has said she can be the permanent monitor for this, and as Firefox
> Perf PM, so that sounds fine
> - For non-expiring probes, we usually require an automated test, because
> it's not undergoing verification or review every 6mo. :bas, can you add a
> test for this probe/feature? Telemetry JS APIs provide the ability to
> snapshot the current state (Telemetry.getScalarSnapshots,
> Telemetry.getHistogramById().snapshot(),...). So a test that clears the
> Telemetry state, run the code, then verifies the correct value was recorded
> by Telemetry.

Umm, I have no idea how to do this, but I can try, Olly, is there some test framework where I could somehow simulate a keyevent or something?

Comment 24

[Bas Schouten (:bas.schouten)]

(In reply to Bas Schouten (:bas.schouten) from comment #23)
> (In reply to Chenxia Liu [:liuche] from comment #22)
> > 
> > As for this specific bug:
> > - Vicky has said she can be the permanent monitor for this, and as Firefox
> > Perf PM, so that sounds fine
> > - For non-expiring probes, we usually require an automated test, because
> > it's not undergoing verification or review every 6mo. :bas, can you add a
> > test for this probe/feature? Telemetry JS APIs provide the ability to
> > snapshot the current state (Telemetry.getScalarSnapshots,
> > Telemetry.getHistogramById().snapshot(),...). So a test that clears the
> > Telemetry state, run the code, then verifies the correct value was recorded
> > by Telemetry.
> 
> Umm, I have no idea how to do this, but I can try, Olly, is there some test
> framework where I could somehow simulate a keyevent or something?

Hrm, I've found something Event.simulateKey, I'm guessing I'm going to use that somehow :-)

Comment 25

[Olli Pettay [:smaug][[e-mail]]]

Explained on IRC.

Comment 26

[Bas Schouten (:bas.schouten)]

I wrote a mochitest here but it turns out we don't allow getting the telemetry data in the child process so it doesn't seem like we can test it that way, I'm not yet sure of a better way, working on it.

Comment 27

[Vicky Chin [:vchin]]

(In reply to Chenxia Liu [:liuche] from comment #22)
> rather than a renewable Tier 2 or 3. I'll send an invite to have this
> discussion.

Sounds good. Thank you for setting that up.

Comment 28

[Bas Schouten (:bas.schouten)]

Attachment: Part 3: Add test for keypress telemetry.

Comment 29

[Markus Stange [:mstange]]

Comment on attachment 9026959 [details] [diff] [review]
Part 3: Add test for keypress telemetry.

Review of attachment 9026959 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/tests/browser/browser_keypressTelemetry.js
@@ +6,5 @@
> +var EventUtils = {};
> +var PaintListener = {};
> +Services.scriptloader.loadSubScript("chrome://mochikit/content/tests/SimpleTest/EventUtils.js", EventUtils);
> +
> +async function getRecordedKeypresses()

Maybe call this getRecordedKeypressCount()? With the current name I'd expect the return value to be an array.

@@ +9,5 @@
> +
> +async function getRecordedKeypresses()
> +{
> +    // If we try to wait less than 2.5 seconds it seems the telemetry data has frequently not yet arrived in the parent process so we need this wait.
> +    return new Promise(resolve => { setTimeout(function () { resolve(Object.values(Services.telemetry.getSnapshotForHistograms("main", false).gpu["KEYPRESS_PRESENT_LATENCY"].values).reduce((a, b) => a += b, 0)); }, 2500); });

A few more line breaks and intermediate variables would make this a lot more readable. For example, the result of the Object.values() call is what I would call allHistogramBucketCounts.
Please replace "a += b" with "a + b".

You can drop the "async" from the function definition. Alternatively, you could keep the async and replace "return new Promise" with "await new Promise".

The setTimeout seems *really* unfortunate; setTimeout is usually banned from tests because it always leads to intermittent test failures. I haven't looked at tests for telemetry before, I'd hope there is some way to wait for telemetry data being reported / available...

Comment 30

[Markus Stange [:mstange]]

chutten, is there a way to wait for the required telemetry data to be available without using setTimeout? I guess since this is reported after compositing, we'll have to wait for a MozAfterPaint event first, and then wait for telemetry data to roundtrip to the parent process and back?

Comment 31

[Chris H-C :chutten]

We use ContentTaskUtils.waitForCondition (see [1] for example) to wait for the Telemetry to make it from the child process to the parent.

On a related note, you can use the pref[2] toolkit.telemetry.ipcBatchTimeout to reduce the delay.

[1]: https://searchfox.org/mozilla-central/source/toolkit/components/telemetry/tests/browser/browser_DynamicScalars.js#11
[2]: https://firefox-source-docs.mozilla.org/toolkit/components/telemetry/telemetry/internals/preferences.html

Comment 32

[Bas Schouten (:bas.schouten)]

Attachment: Part 3: Add test for keypress telemetry. v2

This seems to work well.

Comment 33

[Bas Schouten (:bas.schouten)]

Comment on attachment 9024713 [details] [diff] [review]
Part 2: Add telemetry for keypress presentation latency v2

The guide says feedback but let's try this :-).

Comment 34

[Bas Schouten (:bas.schouten)]

Can we finalize this? :)

Comment 35

[Bas Schouten (:bas.schouten)]

Attachment: Data Review Request

As per IRC.

Comment 36

[Chris H-C :chutten]

Comment on attachment 9028635 [details]
Data Review Request

DATA COLLECTION REVIEW RESPONSE:

    Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes. This collection is Telemetry so it is documented in its definition file (Histograms.json), the Probe Dictionary, and on the telemetry.mozilla.org Measurement dashboards.

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

Yes. This collection is Telemetry so it can be disabled in Firefox's Preferences.

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

No. The request fails to mention an individual who will be responsible for monitoring this over time.

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

Category 2, Interaction.

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

Default on, all channels.

    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.

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

Yes.

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

No, this collection is permanent.

---
Result: datareview-

Needs an individual's name responsible for monitoring this collection if it is permanent. You can either provide an individual (and include them in the alert_emails list) or back this collection down to a six-month collection (expiring it in Firefox 69 or 70 and then renewing it if it proves to be useful).

Comment 37

[Bas Schouten (:bas.schouten)]

Attachment: Data Review Request v2

Comment 38

[Chris H-C :chutten]

Comment on attachment 9028685 [details]
Data Review Request v2

DATA COLLECTION REVIEW RESPONSE:

    Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes. This collection is Telemetry so it is documented in its definition file (Histograms.json), the Probe Dictionary, and on the telemetry.mozilla.org Measurement dashboards.

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

Yes. This collection is Telemetry so it can be disabled in Firefox's Preferences.

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

Yes. Vicky Chin.

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

Category 2, Interaction.

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

Default on, all channels.

    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.

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

Yes.

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

No, this collection is permanent.

---
Result: datareview+

Comment 39

[Bas Schouten (:bas.schouten)]

Attachment: Part 2: Add telemetry for keypress presentation latency v3

Updated to collect on all channels.

Comment 40

[Chris H-C :chutten]

Comment on attachment 9034735 [details] [diff] [review]
Part 2: Add telemetry for keypress presentation latency v3

Review of attachment 9034735 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM

Comment 41

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e254270c043d
Part 1: Register KeyPress events with the LayerManager when painting is scheduled. r=smaug
https://hg.mozilla.org/integration/mozilla-inbound/rev/7462040e3c09
Part 2: Add telemetry probe for keypress presentation latency. r=smaug
https://hg.mozilla.org/integration/mozilla-inbound/rev/2bd9efc39288
Part 3: Add test for keypress telemetry. r=mstange

Comment 42

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/e254270c043d
https://hg.mozilla.org/mozilla-central/rev/7462040e3c09
https://hg.mozilla.org/mozilla-central/rev/2bd9efc39288