`profiler_thread_is_being_profiled` is used a lot for markers, so it makes sense to have a specialized version, which is a bit shorter, and lives in ProfilerMarkers.h.
Differential Revision: https://phabricator.services.mozilla.com/D130009
`profiler_thread_is_being_profiled` is used a lot for markers, so it makes sense to have a specialized version, which is a bit shorter, and lives in ProfilerMarkers.h.
Differential Revision: https://phabricator.services.mozilla.com/D130009
Currently, checking whether an `EventTarget` is `nsINode` (or its concrete
classes) or not requires a QI, but it's expensive and used a lot while we
handle each event. Therefore, it'd be nicer for creating a virtual method,
`EventTarget::IsNode()` and use it for the check.
If trying to convert `EventTarget` to a concrete class, it may require two
virtual method calls. I'm not sure whether it's cheaper than a QI, but at
least, it won't depend on the UUID check order of `QueryInterface()` when
multiple interfaces are implemented.
Differential Revision: https://phabricator.services.mozilla.com/D129781
`ProfilerStringView::Data()` would return a pointer to the start of the string, but there may not be a null terminator at the end!
To reduce the likelihood of misuses, that function has now been removed.
Instead, callers must now access the data through `AsSpan` or the `Span` conversion operator (which makes it easy to use with `NS_ConvertUTF16toUTF8` for example).
It was not an issue until now, because deserialized string would always be terminated when copied out of the profile buffer, but a following patch will add optimized code where the non-terminated string inside the buffer will be directly pointed at.
Differential Revision: https://phabricator.services.mozilla.com/D125027
We did two optimizations in this patch
1. Since mResourceEntries and mUserEntries are presorted
arrays, we could just merge them by iterating them over without
performing a quick sort.
2. Don't perform quick sort if entry type is provided.
Differential Revision: https://phabricator.services.mozilla.com/D124797
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
PerformanceObserver.supportedEntryTypes doesn't check whether
PerformanceEventTiming is enabled or not, so it'll falsely claims
PerformanceEventTiming is supported even if the pref is disabled.
This patch fixes that by adding a guard to it.
Differential Revision: https://phabricator.services.mozilla.com/D114250
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
AutoTArray gives us some memory overhead and the benefits it provides
might not be that useful since PerformanceEventTiming only works
for certain event types.
Differential Revision: https://phabricator.services.mozilla.com/D105078
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
Gerald Squelart
Cristian Tuns
Masayuki Nakano
Evgenia Kotovich
Noemi Erli
Alexandru Michis
amurali
Sean Feng
Olli Pettay
Nazım Can Altınova
Andi-Bogdan Postelnicu
Kagami Sascha Rosylight
Tom Ritter
Tooru Fujisawa
Florian Quèze
Emilio Cobos Álvarez
Peter Van der Beken
Simon Giesecke
smolnar
amurali
Markus Stange
Masatoshi Kimura
Narcis Beleuzu
Dorel Luca