mLocale is currently initialized in IndexedDatabaseManager::Init which is
called from IndexedDatabaseManager::GetOrCreate if the manager doesn't exist.
This can be a problem when IndexedDatabaseManager::GetOrCreate is called very
early,for example in nsLayoutStatics::Initialize in the parent process.
This is a preparation for moving IndexedDatabaseManager::GetOrCreate from
FactoryOp::Open to InitializeQuotaManager.
Differential Revision: https://phabricator.services.mozilla.com/D189891
To allow workers to know the OverriddenFingerprintingSettings,
we populate the value to the worker loadInfo and worker private from
the document.
For service workers, we use the partitionKey in its principal to get
the OverriddenFingerprintingSettings of the given service worker.
Differential Revision: https://phabricator.services.mozilla.com/D185014
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 probably should have been done earlier, but became obvious with uses of Document::HasStorageAccessPermissionGrated in this stack.
Differential Revision: https://phabricator.services.mozilla.com/D184825
This probably should have been done earlier, but became obvious with uses of Document::HasStorageAccessPermissionGrated in this stack.
Differential Revision: https://phabricator.services.mozilla.com/D184825
Before bug 1775784, RemoteWorkerChild's refcount was not threadsafe and
so RemoteWorkerChild-related logic went to great contortions to avoid
trying to create new refcounts off the worker launcher thread, leading
to the logic stealing the caller's RefPtr. However, this was unsound
in the case that the RefPtr would be used after the creation of the
MessagePortIdentifierRuynnable, which was the case if dispatch of the
runnable failed. This fix changes us to the standard XPCOM calling
convention of passing a raw pointer which the MPIR then acquires a
fresh strong refcount. This code is not remotely performance
sensitive and the prior behavior was surprising, so there's no reason
to try and maintain the transfer of the refcount.
Differential Revision: https://phabricator.services.mozilla.com/D180063
Pending->Canceling->Killing (WorkerNeverRan)
Need to clear WorkerPrivate::mPreStartRunnables
Could we call WorkerRunnable::WorkerRun() to release resource? There could be no WorkerGlobalScope...
Pending->Running->Closing->Canceling->Killing(WorkerRan)
Pending->Running->Canceling->Killing(WorkerRan)
When entering “Closing”
1. Keeping receives normal WorkerRunnables
2. Making ParentStatus as Closing
3. Cancel all timeout
4. Don’t clear the main event queue anymore. But we still wait for all SyncLoops be completed.
5. Call WorkerGlobalScope::NoteTerminating() and nsIGlobalObject::DisconnectEventTargetObjects().
6. Switching to “Canceling” by asking parent thread to call WorkerPrivate::Cancel()
When entering “Canceling”
1. Call WorkerGlobalScope::NoteTerminating()
2. Notify StrongWorkerRefs, worker is in “Canceling”, send and complete the corresponding shutdown work right now.
3. Executing all runnables until no normal WorkerRunnables in queue and no WorkerRefs, SyncLoops and children workers
4. Stop receiving normal WorkerRunnables and DisconnectEventTargetObjects of WorkerScope.
4. Entering “Killing”
When entering “Killing”
1. We would not notify WorkerRefs anymore. Logically all WorkerRefs should be released in “Canceling”
2. Executing all remaining ControlRunnables
3. Release corresponding resources of Worker on worker thread.
Depends on D173850
Differential Revision: https://phabricator.services.mozilla.com/D177511
This patch simplifies and cleans up the RemoteWorker state machine by:
- (In a previous patch in the stack) making PRemoteWorker refcounted instead of
ManualAlloc allows us to eliminate use of ThreadSafeWeakPtr and some legwork
that was attempting to ensure we only drop references to RemoteWorkerChild on
the "Worker Launcher" thread.
- Although we are not allowed to call IPC methods on a different thread, we
can absolutely add and remove refcounts on other threads as needed.
- This allowed removal of the `SelfHolder` class as well as a number of calls
to NS_ProxyRelease.
- This allowed removal of the `{get,m}RemoteWorkerControllerWeakRef` hack.
- Adding 2 optional lambda callbacks to the WorkerPrivate constructor that will
be notified on the parent thread in order to simplify tracking the state of
the worker:
- CancellationCallback: Invoked when the parent thread tells the worker to
cancel itself. This can be the automatic result of a script load error,
a call to `self.close()`, or an explicit call to Cancel() by the parent.
- Note that cancellation was always being initiated by the parent thread,
even in the case of `self.close()`!
- TerminationCallback: Invoked when the worker thread has finished and the
WorkerPrivate's self-ref is about to be dropped. This indicates that the
worker transitioned to Killing and fully completed that process.
- Changing the RemoteWorkerChild to always perform state transitions on the
owning parent thread (although the state may be checked from other threads,
more in the code comments).
- The CancellationCallback mechanism replaces a complicated use of
WorkerRefs. This allowed removal of ReleaseWorkerRunnable.
- In general this reduces the number of permutations of thread interactions
we have to worry about.
- Changing the RemoteWorkerChild to only report that the worker has finished
shutting down as a result of the TerminationCallback rather than when the
worker has transitioned to Cancelling.
- Changing the states to better represent the worker's state in terms of
WorkerStatus terminology.
Some related cleanups:
- Use of mechanisms provided by IPC:
- RemoteWorkerChild had an mOwningEventTarget with a GetOwningEventTarget
getter that we were able to replace with the IPC-maintained
GetActorEventTarget().
- We replaced the `mIPCActive` with use of IPC's CanSend().
- MOZ_LOG logging was added under "RemoteWorkerChild".
Differential Revision: https://phabricator.services.mozilla.com/D164644
This patch introduces modules workers to shared workers. This includes the necessary chagnes to pass
the "type: module" to the shared worker. Beyond that, this patch relies on the work landed in
dedicated workers.
Depends on D162743
Differential Revision: https://phabricator.services.mozilla.com/D156103
This patch introduces modules workers to shared workers. This includes the necessary chagnes to pass
the "type: module" to the shared worker. Beyond that, this patch relies on the work landed in
dedicated workers.
Depends on D162743
Differential Revision: https://phabricator.services.mozilla.com/D156103
This patch introduces modules workers to shared workers. This includes the necessary chagnes to pass
the "type: module" to the shared worker. Beyond that, this patch relies on the work landed in
dedicated workers.
Depends on D162743
Differential Revision: https://phabricator.services.mozilla.com/D156103
Previously, we initialized WorkerLoadInfo's shouldRFP member
using the Worker's principal at time of construction. It is
better to populate it from the RemoteWorkerData structure.
The RemoteWorkerData's shouldRFP member can be initialized
with the correct context.
In ServiceWorkerPrivateImpl.cpp it has the same effect, before
and after we use ServiceWorkerInfo.mPrincipal
But for SharedWorker.cpp we previously used
RemoteWorkerData.principalInfo (the second of three principal
members). This was initialized from the WorkerLoadInfo.mPrincipal
member, which in turn came from loadInfo.mChannel which in turn
came from loadInfo.mLoadingPrincipal.
Now we use the WorkerLoadInfo.mShouldResistFingerprinting member
which is initialized from
nsContentUtils::ShouldResistFingerprinting(document) in
WorkerPrivate::GetLoadInfo which can take into account greater
context which will be important in the next few patches.
Differential Revision: https://phabricator.services.mozilla.com/D150590
- Reorder ShouldRFP(char* justification) to put it first
- Add a log line about a null dochsell to be consistent
- Significantly alter the ShouldRFP(nsIPrincipal) check:
Before, it was a coarse function, if you weren't system
principal, it just checked the pref.
Now, it has been combined with the ShouldRFP(nsIPrincipal, OriginAttributes)
function, which was fine-grained. That function didn't
need to exist, because we can _get_ the OriginAttributes
_from_ the principal.
Because before we were retrieving the OA from the loadInfo
(and not the principal) we add an assert to ensure they're
the same.
We eliminate the ShouldRFP(nsIPrincipal, OriginAttributes)
function entirely and convert its one caller into just
passing the principal.
One result of all of this is that the ShouldRFP(nsIPrincipal)
check has been turned into a fine-grained check.
Differential Revision: https://phabricator.services.mozilla.com/D146945
To know if a worker is created under a third-party context, we need to
populate the `IsThirdPartyContextToTopWindow` to WorkerPrivate. This is
needed to get the correct foreign partitioned prinipal when loading
worker script in the content processes.
Differential Revision: https://phabricator.services.mozilla.com/D129059
This commit replaces IPCInternalResponse with three different structs:
ParentToParentInternalResponse, ParentToChildInternalResponse, and
ChildToParentInternalResponse. Doing this lets us convert runtime
checks into compile-time type checks and simplifies relevant code.
Differential Revision: https://phabricator.services.mozilla.com/D131275
To know if a worker is created under a third-party context, we need to
populate the `IsThirdPartyContextToTopWindow` to WorkerPrivate. This is
needed to get the correct foreign partitioned prinipal when loading
worker script in the content processes.
Differential Revision: https://phabricator.services.mozilla.com/D129059
