Using TypedArrayCreator avoids use of ErrorResult completely (and the need to
call MightThrowJSException/WouldReportJSException).
Differential Revision: https://phabricator.services.mozilla.com/D214793
Using TypedArrayCreator avoids use of ErrorResult completely (and the need to
call MightThrowJSException/WouldReportJSException).
Differential Revision: https://phabricator.services.mozilla.com/D214793
This renames address() and unsafeGet() methods to be const and non-const
versions of unsafeAddress.
The unnecessary operator bool() overload is removed.
Differential Revision: https://phabricator.services.mozilla.com/D212260
All present uses of the call-site arguments to MozPromise's methods
supply static strings. However, this is nowhere enforced. Do so.
Additionally, since this is the third or fourth time the present author
alone has personally implemented such an enforcement mechanism, create a
helper class to simplify doing so.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D207462
WorkerRunnable no longer keeps a raw pointer(mWorkerPrivate) for the associated WorkerPrivate in this patch.
Removing the WorkerRunnable::mWorkerPrivate needs to fix the following problems.
1. Thread assertions in WorkerRunnable::Dispatch()
To fix this problem, the associated WorkerPrivate is as a parameter and passed to WorkerRunnable::Dispatch() for the dispatching thread assertions. This associated WorkerPrivate is also propagated to PreDispatch() and PostDispatch() for the children classes of WorkerRunnable()
2. Get the associated WorkerPrivate in WorkerRunnable::Run() for environment setup(GlobabObject, JSContext setting for the runnable)
- For WorkerThreadRunnable
Since WorkerThreadRunnable is supposed to run on the worker thread, it does not need to keep a raw pointer to WorkerPrivate as its class member. GetCurrentThreadWorkerPrivate() should always get the correct WorkerPrivate for WorkerThreadRunnable.
- For WorkerParentThreadRunnable
WorkerParentRef is introduced to keep a RefPtr<WorkerPrivate> for WorkerParentThreadRunnable instead of using a raw pointer.
Checking the associated WorkerPrivate existence by WorkerParentRef at the beginning of WorkerParentThreadRunnable::Run(). If the Worker has already shut down, WorkerParentThreadRunnable cannot do anything with the associated WorkerPrivate, so WorkerParentThreadRunnable::Run() will return NS_OK directly but with a warning.
The associated WorkerPrivate is also passed into WorkerRun(), PreRun(), and PostRun(), so the majority of implementations of child classes of WorkerRunnable do not need to be changed.
If there are any cases in which the child classes of WorkerThreadRunnable/WorkerParentThreadRunnable want to keep the associated WorkerPrivate, they should use WorkerRefs instead of raw pointers.
Depends on D205679
Differential Revision: https://phabricator.services.mozilla.com/D207039
This is the first step in splitting the parent thread runnable out of WorkerRunnable.
To reuse the runnable dispatching codes in Worker, we still need a base class for runnable on the worker thread and the parent thread.
In this patch, we rename the original WorkerRunnable to WorkerThreadRunnable and make WorkerRunnable to be WorkerThreadRunnable's parent class.
In the second patch, we will create WorkerParentThreadRunnable and its sub-classes, split from WorkerThreadRunnable for runnable on the Worker's parent thread.
And in the third patch, we will re-structure the content of WorkerParentThreadRunnable to remove unnecessary members.
Differential Revision: https://phabricator.services.mozilla.com/D205178
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
That was the only case that Promise::CreateInfallible may possibly get nullptr in dom/streams case, so it now just asserts the existence of nsIGlobalObject.
Differential Revision: https://phabricator.services.mozilla.com/D168678
This does not cover helper functions e.g. Promise::CreateResolvedWithUndefined, to get some early feedback and make sure this is safe.
Differential Revision: https://phabricator.services.mozilla.com/D167696
This does not cover helper functions e.g. Promise::CreateResolvedWithUndefined, to get some early feedback and make sure this is safe.
Differential Revision: https://phabricator.services.mozilla.com/D167696
As of the prior patch, these are no longer needed. I removed
these with a script, then ran clang-format on the files, then
manually reverted a few unrelated changed from the formatter.
Differential Revision: https://phabricator.services.mozilla.com/D164829
Peter Van der Beken
Stanca Serban
Jon Coppeard
Ray Kraesig
Eden Chuang
Dave Townsend
Mark Banner
Gregory Pappas
Jens Stutte
Cristian Tuns
Joel Maher
Emilio Cobos Álvarez
Tom Marble
Kagami Sascha Rosylight
Norisz Fay
Kris Maglione
Andi-Bogdan Postelnicu
Sandor Molnar
Iulian Moraru
serge-sans-paille
Marian-Vasile Laza
Andrew McCreight
Jari Jalkanen