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
The System Principal boolean was only used for RFP purposes.
We replace it with an RTPCallerType and populate it not in
the Performance ctor but rather in the CreateFor methods
that will populate it based on the context of their
construction.
Depends on D151305
Differential Revision: https://phabricator.services.mozilla.com/D151306
The System Principal boolean was only used for RFP purposes.
We replace it with an RTPCallerType and populate it not in
the Performance ctor but rather in the CreateFor methods
that will populate it based on the context of their
construction.
Depends on D151305
Differential Revision: https://phabricator.services.mozilla.com/D151306
The System Principal boolean was only used for RFP purposes.
We replace it with an RTPCallerType and populate it not in
the Performance ctor but rather in the CreateFor methods
that will populate it based on the context of their
construction.
Depends on D151305
Differential Revision: https://phabricator.services.mozilla.com/D151306
IsPerformanceTimingAttribute can be called by both Window and WorkerGlobalScope
global objects so we move it to the Performance* superclass.
Differential Revision: https://phabricator.services.mozilla.com/D154819
The converted value gets passed into TimingNotification which assigns the value
into a PerformanceEntry (this is the only usage). Since PerformanceEntry is
defined in WebIDL, we could not change its types (which is double for mEpoch) so
we were forced to safely convert the value where we did.
I don't think the existing conversion code had any bugs since we converted a
64-bit signed integer timestamp into uint64_t (safe) into a double (which is
safe for the reasons mentioned in the code comments).
Differential Revision: https://phabricator.services.mozilla.com/D145142
There's a pattern of clearing JS things when calling mozilla::DropJSObjects,
but mozilla::DropJSObjects already clears the JS things itself by calling
CycleCollectedJSRuntime::RemoveJSHolder.
Differential Revision: https://phabricator.services.mozilla.com/D115885
Various code was passing 'this' to mozilla::DropJSObjects in unlink, but that's
the CC participant. The right object to pass is 'tmp'. I also added static
asserts in mozilla::Hold/DropJSObjects to block this in the future.
Differential Revision: https://phabricator.services.mozilla.com/D115884
By resolving the relevant promises, instead of crashing (and if we
didn't crash we'd leave the window registered as a refresh driver
observer, which would be bad).
I wanted to reject them, since that's what we do when the page has no
pres shell, but that'd make this test fail:
https://searchfox.org/mozilla-central/rev/d8194cbbeaec11962ed67f83aea9984bf38f7c63/dom/base/test/browser_promiseDocumentFlushed.js#165-186
For this, we modify the OneShotPostRefreshObserver API to be more
generic (and rename it OneShotManagedRefreshObserver).
We fix APZ's usage of this API, which was doing something extremely
weird (returning a refcounted object in a UniquePtr). This seems like an
artifact from recent OneShotPostRefreshObserver cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D111851
Currently, whenever the algorithm requires to get timestamps, it'll
try to get the corresponding precision reduced timestamps. However,
this creates some memory overhead because the calculation of precision
reduced timestamps. So instead of always generating the precision
reduced timestamps, we use the raw timestamps internally to avoid
generating precision reduced timestamps unnecessarily.
Differential Revision: https://phabricator.services.mozilla.com/D105829
Upon the construction of `eventCounts`, a wrapper of it will be created
because we set the initial values to 0. This exposes the interface
despite the pref is not set.
Differential Revision: https://phabricator.services.mozilla.com/D104872
Performance event entries should only be retrieved by
PerformanceObserver, so it can't be retrieved by using
Performance.GetEntries* APIs.
Differential Revision: https://phabricator.services.mozilla.com/D102036
