There is a difference between
a) the cycle collector being shut down and
b) the JSContext being destroyed entirely
We can use weak references to cycle collected objects after the CC is destroyed, but not after the JSContext is destroyed.
Thus we need to move `nsCycleCollector_shutdown();` out of the `~WorkerJSContext()` and ensure we check our sentinels before we destroy it.
Differential Revision: https://phabricator.services.mozilla.com/D143061
This patch replaces the previous process selection infrastructure with a
new setup implemented entirely in C++, which should more accurately
track the set of processes in use, and should encourage re-use of the
existing content process when navigating by not counting the current
tab.
This approach intentionally allows for process switching to another
process during navigation if there is uneven load between processes to
encourage balanced process use.
I think this may also fix some of the session restore issues with many
tabs using the same process, rather than being spread over 4, as we now
track a tab earlier in its lifecycle before the BrowserParent instance
is created.
Differential Revision: https://phabricator.services.mozilla.com/D126405
The patch D138442 wanted to guard us against the late use of global scope's reference to WorkerPrivate by nulling it out. The rational behind this was to enforce the invariant, that a `WorkerGlobalScopeBase` derived object should never outlive its `WorkerPrivate`. It turned out that during further worker cleanup at the end of `WorkerThreadPrimaryRunnable::Run` we still process pending events (while the `WorkerPrivate` is still alive) that might want to access the global scope and in particular its `mWorkerPrivate` legitimately.
The purpose of this patch is to:
- Postpone the unrooting until after the last expected event processing.
- Enforce the invariant "Lifetime(global scope) < Lifetime(WorkerPrivate)" by asserting that the global scope went away after GC/CC.
- Do the nulling of global scope's `mWorkerPrivate` only if needed after the CC shut down.
- Do the nulling of debugger global scope's `mWorkerPrivate` while unrooting as it does not support weak references.
Differential Revision: https://phabricator.services.mozilla.com/D141507
* TextEncoder stream tests now fail, rather than error
* WritableStreams are exosed on worker interfacess now; and broken-then is fixed too
* Fix interface semantics
Differential Revision: https://phabricator.services.mozilla.com/D141125
This will be used to avoid problematic includes from WorkerPrivate.h,
and it matches the behavior of RefPtr<> and WeakPtr<>.
Differential Revision: https://phabricator.services.mozilla.com/D140658
This will be used to avoid problematic includes from WorkerPrivate.h,
and it matches the behavior of RefPtr<> and WeakPtr<>.
Differential Revision: https://phabricator.services.mozilla.com/D140658
When the delay value gets converted from double to integer, it
would lose its precision. So the delay of the timer is going to
be smaller than the actual delay that the user expects (by a
tiny bit though).
This patch changes the behavior to always round value upwards.
Differential Revision: https://phabricator.services.mozilla.com/D139773
When the delay value gets converted from double to integer, it
would lose its precision. So the delay of the timer is going to
be smaller than the actual delay that the user expects (by a
tiny bit though).
This patch changes the behavior to always round value upwards.
Differential Revision: https://phabricator.services.mozilla.com/D139773
During shutdown gRuntimeService can be accessed from a different thread while it gets destroyed. There should be not too much penalty having this atomic, even if it is for an edge case only.
Differential Revision: https://phabricator.services.mozilla.com/D139819
This is very similar to a few fixes we've sent your way already, like https://phabricator.services.mozilla.com/D136608. We are merging in the dFPI enabling test config now that all of the test fixes have rolled in, but this test beat us in the race condition.
Reminder:
We are fixing mochitests that fail when network.cookie.cookieBehavior = 5, i.e. when we enable Total Cookie Protection.
This is most often due to the test assuming that an origin will always have access to its storage state when embedded as
a third party.
In this case I had to request storage access to allow an embedded iframe to use a BroadcastChannel to communicate with top-level pages of the same origin.
This was only a problem in the XOrigin case where the test html file is loaded in an embedded iframe and then can't communicate with the top-level window it created.
Differential Revision: https://phabricator.services.mozilla.com/D138850
Iulian Moraru
Jens Stutte
Narcis Beleuzu
Tom Schuster
Randell Jesup
Norisz Fay
Gijs Kruitbosch
Butkovits Atila
Nika Layzell
Olli Pettay
Ryan Hunt
criss
asharma
Joel Maher
Tom Ritter
Eden Chuang
Matthew Gaudet
Emilio Cobos Álvarez
Noemi Erli
Marian-Vasile Laza
Chris Peterson
Sean Feng
Benjamin VanderSloot