Remove mWorkerPrivate from WorkerMainThreadRunnable. Instead, using a ThreadSafeWorkerRef to keep Worker alive until the created syncLoop is destroyed.
In general, WorkerMainThreadRunnable::mWorkerPrivate is only used for dispatching the MainThreadStopSyncLoopRunnable back to the Worker thread. Because of the syncLoop, the Worker is supposed to be kept alive until the created syncLoop is destroyed.
RefPtr<ThreadSafeWorkerRef> WorkerMainThreadRunnable::mWorkerRef is introduced to ensure a valid WorkerPrivate during WorkerMainThreadRunnable's execution.
WorkerMainThreadRunnable::mWorkerRef is allocated just before creating a syncLoop in WorkerMainThreadRunnable::Dispatch. And released after the created syncLoop::Run() finishes.
Depends on D212556
Differential Revision: https://phabricator.services.mozilla.com/D212557
The resolved URL is passed to alert service as expected already, and this patch makes sure Notification object itself stores the resolved URL as the spec says.
Safari and Chrome already conform to the spec.
Removing test_notification_get as it's now covered by WPT and modifying notification_worker as WPT doesn't cover dedicated workers yet (as testdriver limitation makes it hard).
Differential Revision: https://phabricator.services.mozilla.com/D208132
The resolved URL is passed to alert service as expected already, and this patch makes sure Notification object itself stores the resolved URL as the spec says.
Safari and Chrome already conform to the spec.
Removing test_notification_get as it's now covered by WPT and modifying notification_worker as WPT doesn't cover dedicated workers yet (as testdriver limitation makes it hard).
Differential Revision: https://phabricator.services.mozilla.com/D208132
This unfortunately adds some ASCII-to-UTF16 conversion because:
1. Enums use nsLiteralCString internally
2. nsAlertsService expects nsString. (macOS and Windows expects UTF16 while libnotify expects UTF8)
3. ServiceWorker events currently expect nsString. Fixing this requires touching quite some files and I filed bug 1894240 for that.
Differential Revision: https://phabricator.services.mozilla.com/D208920
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
This patch is only remove the inheriting, but keeping Cancel() implmentation.
The Cancel() is needed in some special cases, such as Worker enters Canceling when WorkerScope is not created.
Depends on D176915
Differential Revision: https://phabricator.services.mozilla.com/D173850
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 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 adds context to `CloseAlert()` such that explicitly closing the notification e.g. `notification.close()` can be differentiated from a tab or window implicitly closing the notification. This is necessary as we want notifications to persist after a tab or window is closed for Windows.
This change in behavior is necessary to match user expectations. Users expect notifications to persist in the system tray and do not expect notifications to be lost due to a tab being closed. The content of the message is more important than the interaction in that lens. This change is also necessary for parity with Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D161024
We disallow notification permission requests from cross-origin iframes (see bug 1560741).
It makes sense that we also disallow showing notification from cross-origin iframes,
even if user has granted the notification permission on that origin.
Differential Revision: https://phabricator.services.mozilla.com/D158147
