I initially tried to write a WPT test for this. But I failed to do so
because the test driver for WPT doesn't accept a pointerdown without any
matching pointer events. So either it just doesn't fire a pointerdown or
it fires pointerup with it. So that's why I chose to write one in
mochitest instead.
The test first fires a pointerdown with no up, and then fires another
pointerdown with an up instead. So the second pointerdown should clear
the old one and set its interactionId to zero. So first one should have
interactionId of zero and the second should have a non-zero
interactionId.
Differential Revision: https://phabricator.services.mozilla.com/D252110
This issue seems like it's very hard to reproduce, and only happens
after keeping Firefox running after a few days. I noticed that it mostly
happens in the parent process, where it stops dispatching event timing
entries because of an unknown interactionId of a pointerdown event.
This seems to happen when a pointerdown event is fired but no pointerup,
pointercancel or contextmenu events are fired after that that match it.
I don't exactly know in which cases it happens, but I saw it happen in
the wild. If we clear the flush the older pending entries before
overriding them in the pendingPointerdowns map, we can solve this issue.
This is not in the spec, but Chrome already has this check. I updated
the spec issue to mention this in the spec as well once we rework the
pendingPointerdowns logic.
Differential Revision: https://phabricator.services.mozilla.com/D252109
I initially tried to write a WPT test for this. But I failed to do so
because the test driver for WPT doesn't accept a pointerdown without any
matching pointer events. So either it just doesn't fire a pointerdown or
it fires pointerup with it. So that's why I chose to write one in
mochitest instead.
The test first fires a pointerdown with no up, and then fires another
pointerdown with an up instead. So the second pointerdown should clear
the old one and set its interactionId to zero. So first one should have
interactionId of zero and the second should have a non-zero
interactionId.
Differential Revision: https://phabricator.services.mozilla.com/D252110
This issue seems like it's very hard to reproduce, and only happens
after keeping Firefox running after a few days. I noticed that it mostly
happens in the parent process, where it stops dispatching event timing
entries because of an unknown interactionId of a pointerdown event.
This seems to happen when a pointerdown event is fired but no pointerup,
pointercancel or contextmenu events are fired after that that match it.
I don't exactly know in which cases it happens, but I saw it happen in
the wild. If we clear the flush the older pending entries before
overriding them in the pendingPointerdowns map, we can solve this issue.
This is not in the spec, but Chrome already has this check. I updated
the spec issue to mention this in the spec as well once we rework the
pendingPointerdowns logic.
Differential Revision: https://phabricator.services.mozilla.com/D252109
This keypress event is not in the spec yet, but it's in the process of
being added. The logic is quite simple because before every keypress
event there has to be a keydown event right before it. So we simply use
the current interaction value of that keydown entry.
Differential Revision: https://phabricator.services.mozilla.com/D251400
mLastKeydownInteractionValue was initially assigned in keyup instead of
keydown because the spec was initially generating the interactionId of
keydown while we are at keyup, so it was delaying the keydown events.
But since bug 1964426, we don't do this delayed assignment for keydown
events.
So it's a lot easier to implement the correct fix for this after bug 1964426.
Now we simply move this mLastKeydownInteractionValue assignment
to keydown event. Which is the correct location.
Differential Revision: https://phabricator.services.mozilla.com/D251380
There was an update to LCP spec such that the `renderTime` is no longer
protected by Timing-Allow-Origin due to it's easy to side channel attack
it and it isn't needed for CORS protected images.
The solution was to coarsen the timestamp by 4ms (this is what Chrome did).
To do something similar in Firefox, we don't need to coarsen the
timestamp because we already reduce more precisions. We just need to
always expose this.
Spec discussion: https://github.com/w3c/largest-contentful-paint/issues/111
Differential Revision: https://phabricator.services.mozilla.com/D247492
There was an update to LCP spec such that the `renderTime` is no longer
protected by Timing-Allow-Origin due to it's easy to side channel attack
it and it isn't needed for CORS protected images.
The solution was to coarsen the timestamp by 4ms (this is what Chrome did).
To do something similar in Firefox, we don't need to coarsen the
timestamp because we already reduce more precisions. We just need to
always expose this.
Spec discussion: https://github.com/w3c/largest-contentful-paint/issues/111
Differential Revision: https://phabricator.services.mozilla.com/D247492
This patch doesn't change the behavior of the keydown and pointerdown logic.
But it's needed for the next patch which I will change the keydown behavior and
make it non-lazy.
Differential Revision: https://phabricator.services.mozilla.com/D247839
This patch implements PaintTimingMixin with only the `paintTime`, without the
`presentationTime`. The presentationTime property is nullable in the spec and
the browsers might choose to not implement it. We would like to implement it
in the future, but we will do that as a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D247305
Previous implementation was waiting for all entries in the list to be queued to
have known interactionIds. But that delays dispatching some event entries when
there are a lot of events being dispatched quickly, like typing very fast or
smashing the keyboard. So this helps in those cases where there are a lot of
events being waited to be queued.
Differential Revision: https://phabricator.services.mozilla.com/D246576
In bug 1889943 "Firefox :: Translation" was renamed to "Firefox :: Translations"
In bug 1956746 "Core :: DOM: Performance" became "Core :: DOM: Performance APIs"
I had to manually add "Toolkit :: Default Browser Agent" back into tags.yaml
because that component is not built on Linux (which is the platform on which I
ran ./mach update-glean-tags).
Differential Revision: https://phabricator.services.mozilla.com/D244667
This patch tries to follow the spec as much as possible. But unfortunately this
wasn't enough to pass all the web-platform tests and there were some issues
in the spec logic.
I'm adding the fixes to various issues in the following patches, to easily see
what needs to be updated in the spec. Please see the following patches.
Spec: https://w3c.github.io/event-timing/#sec-computing-interactionid
Differential Revision: https://phabricator.services.mozilla.com/D239185
The spec for dispatching the first-input event can be found here:
https://w3c.github.io/event-timing/#sec-dispatch-pending
Specifically step 6.2.2 handles this part of the code change.
The old code was following the spec, but some web-platform-tests were failing
because of it. After looking at the Chromium's codebase, I noticed that it
doesn't match the spec and it has this additional check. After adding it to our
code, it passes the tests as well. So it's clear that the spec doesn't match
the web platform tests or the Chromium implementation. It's more likely that
the spec needs to be updated.
Filed a spec bug here:
https://github.com/w3c/event-timing/issues/142
Differential Revision: https://phabricator.services.mozilla.com/D238470
Bug 1899734 is going to cache the performance timing data from previous fetch
for the subsequent cached fetch.
All non-timing-related fields associated with the response are moved to
CacheablePerformanceTimingData.
Differential Revision: https://phabricator.services.mozilla.com/D223345
As per comments in bug 1910411's patches and others, it's not a useful
metric, specially now that we have LCP and so on.
Actually there doesn't seem to be any consumer of it since bug 1892001.
Differential Revision: https://phabricator.services.mozilla.com/D218489
Two changes are introduced:
* LCP has a hashtable called `ContentIdentifiersForLCP` to store
(element, image) pairs to avoid processing the same pair multiple
times. Instead of using weak pointers for elements, this patch changes
it to use raw pointers for better performance. Also, makes the
hashtable to use element alone as the key, so that the entry
can be quickly removed when nsINode::LastRelease is called.
* Another change to make imgRequestProxy stores the
timestamps for LCP, so we can create LCP entries when the size
is available, instead of creating one temporarily and updating it
later. This allows us to eliminate a hashtable called
`mImageLCPEntryMap` for better performance.
Differential Revision: https://phabricator.services.mozilla.com/D214315
