Currently we store the raw `StartTime` as a `TimeStamp` object, and
convert it to `DOMHighResTimeStamp` when calling `StartTime()`. However,
there's no need to do the conversion every time.
Depends on D96295
Differential Revision: https://phabricator.services.mozilla.com/D96296
PerformanceResourceTiming recalculates the startTime every time when
`StartTime()` method is called, which slows down `GetEntriesByName()`
due to this method requires `StartTime()` to order the entries.
In addition to that, there's not need to recalculate it every time, since all
required timings are already set when the `PerformanceTimingData`
object is first created.
This patch calculates the `startTime` in the constructor and caches it.
Differential Revision: https://phabricator.services.mozilla.com/D96295
This backs out part of bug 1656211 which turned out to be insufficient.
The invalidate rendered frame transaction races with the initial frame
rendering of the popup. If it comes in too soon, we will only draw the
frame once, and the frame corruption remains. This patch makes us flush
the rendering pipeline to ensure we get two separate generate frame
events.
Differential Revision: https://phabricator.services.mozilla.com/D96157
Recording events involved asking whether they should go in the event ping or
not, and also whether we hit the limit for how many are allowed in a ping.
These values are stored in prefs which aren't terribly accessible off the main
thread, even if the event recording is.
Both of these prefs have been set in stone in their default values for over two
years now, so we can safely remove them and their scaffolding. Huzzah!
Differential Revision: https://phabricator.services.mozilla.com/D96102
Previous `purgeRequestForDestroy` method was only rejecting all pending requests.
The new `syncFrontDestroy` allows to fully destroy the front, including
unregistering it/unmanage it. So that if we receive a packet from a brand new
actor, with the same prefix and actor ID, DevToolsClient.getFront doesn't return
the old destroyed front.
This issue was making pending requests that were never resolved.
Differential Revision: https://phabricator.services.mozilla.com/D94718
Add tests that on-/off-thread compiles trigger off-thread compression if it
is available. Add `js::IsOffThreadSourceCompressionEnable()` method to
indicate if the automatic compression is enabled for the process.
Differential Revision: https://phabricator.services.mozilla.com/D92804
This one is even more subtle. This could cause a call from SetStatus()
to OnFontFaceStatusChange() to not be done as part of the load()
function (if the face is about to get added to the set or such).
However, when it's actually added via UpdateRules, we'd properly
invalidate the relevant state as well, so I think this is also fine, and
our existing tests also agree.
Depends on D96342
Differential Revision: https://phabricator.services.mozilla.com/D96343
Font loading invalidation may invalidate only pseudo-elements, like it
happens on this test-case.
Once we get to testing first-line / first-letter in the test-case
(css/css-values/ch-pseudo-recalc-on-font-load.html), we end up flushing
because those end up posting the restyle to the parent element
correctly.
Differential Revision: https://phabricator.services.mozilla.com/D96373
This is vendoring the Glean Rust Language Bindings (built on the
top of glean-core), providing a nice Glean SDK Rust API for consumers,
for using in FOG.
Differential Revision: https://phabricator.services.mozilla.com/D96227
This additionally brings in two more Rust dependencies:
adler and autocfg. They are included in one of the latest
flate2 version.
Differential Revision: https://phabricator.services.mozilla.com/D96226
This needs to count encrypted data, therefore it is implemented as a NSPR layer right above the PR_NSPR_IO_LAYER layer.
Differential Revision: https://phabricator.services.mozilla.com/D96083