This patch adds the ability for Windows on ARM to launch either x86 or
ARM Widevine plugins. It also adds the ability for Windows on x86 to
refuse ARM binaries in case, for example, a profile is transferred
between machines.
Overall this should be a non-functional change for users at the time of
landing. It does however allow us to ship the ARM Widevine plugin to
Windows ARM users to workaround a plugin crash with the x86 Widevine
plugin. This only affects Windows 10 users (Windows 11 works fine).
Differential Revision: https://phabricator.services.mozilla.com/D167634
And use nsID::ToProvidedString(...) method when suitable.
This naturally fixes a memory leak in dom/fetch/FetchParent.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D167606
And use nsID::ToProvidedString(...) method when suitable.
This naturally fixes a memory leak in dom/fetch/FetchParent.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D167606
Added WebIDL interfaces as per spec, added some necessary changes to support maplike and setlike structures to be accessed from C++.
Added `::highlight(foo)` pseudo element to CSS engine.
Implemented Highlight as new kind of `Selection` using `HighlightType::eHighlight`. This implies Selections being added/removed during runtime (one `Selection` object per highlight identifier), therefore a dynamic container for highlight `Selection` objects was added to `nsFrameSelection`. Also, the painting code queries the highlight style for highlight Selections.
Implementation is currently hidden behind a pref `dom.customHighlightAPI.enabled`.
Differential Revision: https://phabricator.services.mozilla.com/D164203
Tests for about:memory doesn't know about utility processes. Make sure
to hide the utility process reporter when needed, and count the number
of living processes, also when needed.
Differential Revision: https://phabricator.services.mozilla.com/D167662
Tests for about:memory doesn't know about utility processes. Make sure
to hide the utility process reporter when needed, and count the number
of living processes, also when needed.
Differential Revision: https://phabricator.services.mozilla.com/D167662
Added WebIDL interfaces as per spec, added some necessary changes to support maplike and setlike structures to be accessed from C++.
Added `::highlight(foo)` pseudo element to CSS engine.
Implemented Highlight as new kind of `Selection` using `HighlightType::eHighlight`. This implies Selections being added/removed during runtime (one `Selection` object per highlight identifier), therefore a dynamic container for highlight `Selection` objects was added to `nsFrameSelection`. Also, the painting code queries the highlight style for highlight Selections.
Implementation is currently hidden behind a pref `dom.customHighlightAPI.enabled`.
Differential Revision: https://phabricator.services.mozilla.com/D164203
Added WebIDL interfaces as per spec, added some necessary changes to support maplike and setlike structures to be accessed from C++.
Added `::highlight(foo)` pseudo element to CSS engine.
Implemented Highlight as new kind of `Selection` using `HighlightType::eHighlight`. This implies Selections being added/removed during runtime (one `Selection` object per highlight identifier), therefore a dynamic container for highlight `Selection` objects was added to `nsFrameSelection`. Also, the painting code queries the highlight style for highlight Selections.
Implementation is currently hidden behind a pref `dom.customHighlightAPI.enabled`.
Differential Revision: https://phabricator.services.mozilla.com/D164203
Added WebIDL interfaces as per spec, added some necessary changes to support maplike and setlike structures to be accessed from C++.
Added `::highlight(foo)` pseudo element to CSS engine.
Implemented Highlight as new kind of `Selection` using `HighlightType::eHighlight`. This implies Selections being added/removed during runtime (one `Selection` object per highlight identifier), therefore a dynamic container for highlight `Selection` objects was added to `nsFrameSelection`. Also, the painting code queries the highlight style for highlight Selections.
Implementation is currently hidden behind a pref `dom.customHighlightAPI.enabled`.
Differential Revision: https://phabricator.services.mozilla.com/D164203
Due to the possible presence of canceled timers at the "front" of the
list, mTimers[0] won't necessarily hold the next timer to be fired
unless we've cleaned up those front timers recently.
Differential Revision: https://phabricator.services.mozilla.com/D166575
The previous version used IndexOfFirstElementGt which is implemented
with a binary search. That doesn't work correctly because the mTimers
array that is being searched is maintained in sorted order
*only if the "cancelled" timers are skipped*. This revision replaces the
binary search with a linear search which can handle this without
problem. Given that the number of timers present at any one time is
fairly modest, a linear search is probably a more appropriate choice
anyway.
Also added a new function, VerifyTimerListConsistency, which is called
once per wake-up in the main loop and enabled only in DEBUG builds, that
checks mTimers for ordering and consistency.
Differential Revision: https://phabricator.services.mozilla.com/D164294
This makes the code more complex, but it is needed to keep this most-used
function efficient related to its old implementation using `std::push_heap`.
Differential Revision: https://phabricator.services.mozilla.com/D164292
Inserting elements in the sorted array is more costly than pushing to a binary
heap, but this is balanced by the removal of indirections and de/allocations,
and the upcoming re-use of empty entries.
In the end, this change is necessary to allow future improvements like timer-
coalescing, where we'll need to see multiple timers in order.
Bonus: FindNextFireTimeForCurrentThread changes a lot, because it used to have
to `pop_heap` elements and then `push_heap` them back! (Sometimes resulting in
subtle changes for timers with the same timeout.) So this one benefits the
most.
Differential Revision: https://phabricator.services.mozilla.com/D164291
So entries now store the given timeout value (instead of clamping it to after "now").
And we store this timeout first, as it's accessed more frequently.
Differential Revision: https://phabricator.services.mozilla.com/D164288
Previously we'd always read the full stream, but if an aCount lower than
the actual size of the stream is provided, we should only encode that
many bytes.
This patch also improves handling of streams shorter than aCount bytes,
ensuring that the generated string is of the correct length.
Differential Revision: https://phabricator.services.mozilla.com/D166616
This method always returned GetMainThreadSerialEventTarget(). This patch
switches all callers over to use that method instead.
We can't easily switch all calls to be calls to NS_GetMainThread(), as there is
no version of that method returning a bare nsIThread* instance.
I didn't introduce one, as we may want to add a lock around mMainThread in the
future, which would require removing nsThreadManager::GetMainThreadWeak. As
this method only returns nsISerialEventTarget, it method could remain
implemented, however, by returning a statically allocated fake event target
which forwards dispatches (and QIs to nsIThread) to the real main thread.
Differential Revision: https://phabricator.services.mozilla.com/D166608
This only changes the behaviour when called with a TaskQueue or other type
using SerialEventTargetGuard on the stack. They are being switched over as the
existing GetCurrentEventTarget method is being removed, as it is somewhat
confusing, and poorly documented.
Callers which need to get the current thread even when on a threadpool or
behind a TaskQueue were switched to GetCurrentEventTarget in the previous part.
Differential Revision: https://phabricator.services.mozilla.com/D166607
These callers are depending on the existing behaviour which always returns a
thread, and does not respect custom TaskQueues. In the next part, all remaining
callers will be switched to GetCurrentSerialEventTarget.
Differential Revision: https://phabricator.services.mozilla.com/D166606
We aren't likely to try to make these changes any time soon, so cleaning out
these unnecessary methods which just return `this` will simplify things.
I was unable to find any calls to the `.eventTarget` getter in JS, which makes
sense, as the nsIThread type is only really used in JS as a wrapper around the
main thread in older code. Because of that, it has been removed as well.
Differential Revision: https://phabricator.services.mozilla.com/D166605
This will help catch issues such as the one from bug 1806751, as we will assert
earlier in the process. This also aligns better with the existing documentation
of the method (which has been updated), which suggests that the method would
assert if called on a thread pool.
Differential Revision: https://phabricator.services.mozilla.com/D166604
Jon Coppeard
Andrew Osmond
Andrew McCreight
Nika Layzell
serge-sans-paille
Olli Pettay
Norisz Fay
Narcis Beleuzu
Jan-Niklas Jaeschke
Andreas Farre
Sandor Molnar
Gabriele Svelto
Peter Van der Beken
Noemi Erli
Justin Link
Gerald Squelart
Emilio Cobos Álvarez
Iulian Moraru
alwu
Artur Iunusov