1761018 - SharedWorker::Constructor needs to handle the system principal creating a SharedWorker in private browsing mode

Status: RESOLVED FIXED

(Core :: DOM: Workers, defect, P3)

Description

[Andrew Sutherland [:asuth] (he/him)]

One of the side-effects of private-browsing mode[1] is that system-principal'ed windows will indicate they are in private browsing mode but the system principal itself can never have an mPrivateBrowsingId. This requires assertion checks like the one in SharedWorker::Constructor to handle this, and we need to accordingly update (or remove) this check.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

Attachment: Bug 1761018 - System Principaled SharedWorkers in Private Browsing windows should not assert. r=#dom-workers!

Currently we allow the System Principal to create SharedWorkers (and we
want to continue supporting this). In private browsing windows, however,
StorageAllowedForWindow returns ePrivateBrowsing and a
MOZ_DIAGNOSTIC_ASSERT origin-attribute check gets upset, effectively
breaking the use of SharedWorkers.

We address this by following our existing idiom for other storage-keyed
APIs where we special-case the system principal in our API logic and only
call StorageAllowedForWindow if we're not dealing with the system principal.

Because the SharedWorker::Constructor uses the StorageAccess value to
impact additional behavioral checks related to use of the partitioned
principal, we assign StorageAccess::eAllow in the system principal case.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/145f527cea50
System Principaled SharedWorkers in Private Browsing windows should not assert. r=dom-worker-reviewers,smaug

Comment 3

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/145f527cea50