This adds information about interactions during a pageload session to the pageload event. It adds a number of different metrics that will help us understand the distribution of interaction timings. In the longer term this is intended to help us decide what the best metric is for us to consider for the eTLD+1 pageload event.
Differential Revision: https://phabricator.services.mozilla.com/D302799
Modal dialogs (alert, confirm, prompt, print, beforeunload) and context
menus provide visual feedback before the next paint. Record their
appearance time as a fallback so that event timing processingEnd and
duration are not inflated by time spent in the dialog.
This is again related to the spec bug: https://github.com/w3c/event-timing/issues/154
Differential Revision: https://phabricator.services.mozilla.com/D288422
This is a spec bug currently: https://github.com/w3c/event-timing/issues/123
When no paint is pending, event timing entries would stay in the pending
queue indefinitely until unrelated activity triggered a repaint. For
example, a keydown event on a div that doesn't trigger any paint. The
following patch adds a wpt test for this specifically.
Differential Revision: https://phabricator.services.mozilla.com/D288419
This patch converts the mDuration of PerformanceEventTiming from
DOMHighResTimeStamp to Maybe<DOMHighResTimeStamp>. This allows us to
distinguish between:
- Duration not yet set (mDuration.isNothing())
- Duration explicitly set to 0 (mDuration.isSome() && value == 0)
This distinction is necessary to fix bug 2000426, where we need to
determine if a pointerdown event's duration has been finalized before
processing subsequent pointerup/click events.
Differential Revision: https://phabricator.services.mozilla.com/D273025
Previously we were passing strings to the constructor for
PerformanceEntry types, but we don't need that since we know them for
sure during the compile time. It makes it easier to use the static
atoms, and they should be faster than the previous code.
Differential Revision: https://phabricator.services.mozilla.com/D268543
Previously, it was called DispatchBufferFullEvent confusingly, but it
actually dispatches an event called resourcetimingbufferfull.
Differential Revision: https://phabricator.services.mozilla.com/D268520
Most changes are automated. Relevant bit is dom/.clang-format. I had to
manually disable clang-format in a few places where importing external
files and so on that aren't self-contained, and fix a couple includes /
forward declarations.
Differential Revision: https://phabricator.services.mozilla.com/D256800
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
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
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
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
When we generate LCP entries, we store the precision-reduced
timestamps which are convenient for later usages, but not very
performant. This patch makes it instead of storing the
precision-reduced timestamps, store the raw timestamps, and only
reduce the precision when they're being used by user code.
Also, this patch changes how we compute precision-reduced timestamps for LCP.
Currently, we effectively use `ReduceTimePrecisionAsMSecsRFPOnly` to
reduce precision which only work in RFP mode. This patch changes it
to `ReduceTimePrecisionAsMSecs` to make it work in 'Normal' mode (i.e.
non-COOP/COEP pages).
Differential Revision: https://phabricator.services.mozilla.com/D200200
When RFP is enabled and you're dealing with timestamps of
reduced precision, it's possible for these timestamps to
be equal. Relax the assertion to allow that.
Also, conceptually, it should be <= even without RFP because
you can't guarantee the OS timestamps are going to be reliable
(just increasing) and you can't guarantee anything about how
fast or slow computation is going to happen.
Differential Revision: https://phabricator.services.mozilla.com/D197946
There might be multiple LCP entries in a web page, and we only care about the
last one which is also the biggest value. That's why we need to record these
values in two different places:
- During the Document unload, so we can add markers for the closed pages.
- During the profile capture, so we can add markers for the open pages.
This allows us to capture all the LCP values. Note that this is not the case
for other metrics like FCP, TTFB, DOMContentLoaded etc. that fires only once.
Differential Revision: https://phabricator.services.mozilla.com/D192828
There might be multiple LCP entries in a web page, and we only care about the
last one which is also the biggest value. That's why we need to record these
values in two different places:
- During the Document unload, so we can add markers for the closed pages.
- During the profile capture, so we can add markers for the open pages.
This allows us to capture all the LCP values. Note that this is not the case
for other metrics like FCP, TTFB, DOMContentLoaded etc. that fires only once.
Differential Revision: https://phabricator.services.mozilla.com/D192828
There might be multiple LCP entries in a web page, and we only care about the
last one which is also the biggest value. That's why we need to record these
values in two different places:
- During the Document unload, so we can add markers for the closed pages.
- During the profile capture, so we can add markers for the open pages.
This allows us to capture all the LCP values. Note that this is not the case
for other metrics like FCP, TTFB, DOMContentLoaded etc. that fires only once.
Differential Revision: https://phabricator.services.mozilla.com/D192828
Bas Schouten