* Makes it possible to selectively enable TRR for pbmode/container/window/etc
Differential Revision: https://phabricator.services.mozilla.com/D48363
--HG--
extra : moz-landing-system : lando
- Reset idle timeout when dispatching service worker operations even if the
worker is alive.
- Use MessageEvent instead of FetchEvent to avoid creating objects that leak
when the test finishes.
Differential Revision: https://phabricator.services.mozilla.com/D51016
--HG--
extra : moz-landing-system : lando
Keeping track of these registrations is needed for when
ServiceWorkerManager::MaybeStartShutdown is called for the first time. At this
point, all living service workers must register themselves with the
ServiceWorkerShutdownBlocker. Non-idle registrations that are unregistered and
not controlling clients would otherwise not be found in the SWM's data.
Differential Revision: https://phabricator.services.mozilla.com/D50500
--HG--
extra : moz-landing-system : lando
After sw-e10s enabled in nightly, following tests should be passsed with Fission
dom/serviceworkers/test/browser_devtools_serviceworker_interception.js
dom/serviceworkers/test/test_cookie_fetch.html
dom/serviceworkers/test/test_csp_upgrade-insecure_intercept.html
dom/serviceworkers/test/test_eventsource_intercept.html
dom/serviceworkers/test/test_hsts_upgrade_intercept.html
dom/serviceworkers/test/test_https_fetch.html
dom/serviceworkers/test/test_https_fetch_cloned_response.html
dom/serviceworkers/test/test_https_origin_after_redirect.html
dom/serviceworkers/test/test_https_origin_after_redirect_cached.html
dom/serviceworkers/test/test_https_synth_fetch_from_cached_sw.html
dom/serviceworkers/test/test_importscript_mixedcontent.html
dom/serviceworkers/test/test_sanitize_domain.html
This patch enables these tests.
Differential Revision: https://phabricator.services.mozilla.com/D50032
--HG--
extra : moz-landing-system : lando
The idea is to stop directly accessing EnumTypeValues::strings in type-unsafe
ways from consumer code.
Differential Revision: https://phabricator.services.mozilla.com/D49533
--HG--
extra : moz-landing-system : lando
Owing to a lack of test coverage, the changes in bug 1469048 regressed our
de facto privacy/devtools API at nsIServiceWorkerManager.propagateUnregister
to no longer wipe the given registration. The intent of that bug's changes
was to stop the now-moot propagation, but that particular intentional mis-use
of the API was missed.
This patch fixes the problem but maintains the parent-intercept behavior of
only calling ServiceWorkerRegistrar::UnregisterServiceWorker only once.
Differential Revision: https://phabricator.services.mozilla.com/D49996
--HG--
extra : moz-landing-system : lando
Please note that it is the first reformat with clang-format 9
I only saw a fix in the .mm file
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D49056
--HG--
extra : moz-landing-system : lando
Most of these tests have been disabled for a long time; they run well
in the current test environment.
I intend to enable still more mochitests in a future patch.
Differential Revision: https://phabricator.services.mozilla.com/D49524
--HG--
extra : moz-landing-system : lando
When Fission is on, loading a cross-origin iframe triggers process switching when calling the channel::OnStartReqeust.
If a ServiceWorker should intercept the loading, the interception setting is completed while opening the channel.
That means the service worker controls the ClientSource created by the old process.
After process switching completed, the new ClientSource will be created and resume the loading from the opened channel.
However, in the original code, we did not update the controlled Client in the ServiceWorkerManager.
And when loading the same origin subresource in the new process, it makes ServiceWorkerManager cannot find the correct ServiceWorker to perform the interception.
Since we are going to release sw-e10s, this patch is only for both Fission and sw-e10s are on.
Differential Revision: https://phabricator.services.mozilla.com/D49284
--HG--
extra : moz-landing-system : lando
This is effectively a reversion of the change made in
https://hg.mozilla.org/mozilla-central/rev/89c938649297#l1.39 when
DOMMozPromiseRequestHolder was introduced. I've tried to add some
comments to contextualize what's happening there and why it differs
from other similar callsites.
Longer term we might move to just deleting the underlying actor when
we are disconnected. Those actors were written assuming an
execution model where letting either end delete the actor would result
in intentional process crashes when a message was received for a
destroyed actor. That is no longer the case.
Differential Revision: https://phabricator.services.mozilla.com/D49671
--HG--
extra : moz-landing-system : lando
In ServiceWorkerPrivateImpl::SendFetchEvent, a heap-allocated AutoIPCStream can
point to a stack-allocated IPCStream (part of an IPCInternalRequest). If this
IPCStream is destroyed before the AutoIPCStream, the AutoIPCStream will have a
dangling pointer (and this is the case if SendFetchEvent is called when the
Service Worker's state is "activating" rather than "activated").
This patch moves around the logic to handle the AutoIPCStream's lifetime to
ensure it its lifetime is within its IPCStream's lifetime. The larger issue
might be that AutoIPCStream doesn't have inherent lifetime guarantees (it'll
definitely outlive its IPCStream if it points to its embedded one, but it
doesn't own any external IPCStreams it might point to).
Differential Revision: https://phabricator.services.mozilla.com/D48935
--HG--
extra : moz-landing-system : lando
The changes are just cleanup for member variables/methods that should
be private to ServiceWorkerManager.
Differential Revision: https://phabricator.services.mozilla.com/D48181
--HG--
extra : moz-landing-system : lando
Also replace ServiceWorkerManager shutdown logic's normal for-loops with
range-based for-loops.
Differential Revision: https://phabricator.services.mozilla.com/D48179
--HG--
extra : moz-landing-system : lando
- Listen for observer topics in the parent-process when in parent intercept mode
- Remove an extra postMessage call (and the corresponding message handler)
Differential Revision: https://phabricator.services.mozilla.com/D44513
--HG--
extra : moz-landing-system : lando
Previously, Service Workers could spawn in a process that isn't subscribed
to permission updates, which could happen if that process hadn't loaded any
same-origin documents. To address this, parent-process logic for spawning
Service Workers would snapshot the permissions state to be sent to a content
process.
Unfortunately, this approach could lead to outdated, unsynchronized permissions.
Note that nsIPermissionManager::SetPermissionsWithKey is only used to initialize
permissions for a given key and is a no-op if already called with the same key
in a given process. As a result, the following sequence of events could happen:
Assume a content process CP that isn't subscribed to permission changes for an
origin A:
1) Parent process decides to spawn an origin A Service Worker in CP,
snapshotting a value V for permission P.
2) The Service Worker is spawned in CP, setting CP's permission manager's
permission P to value V (for origin A).
3) Parent process updates its permission P to a value A', which is not
broadcasted to CP (because it's not subscribed).
4) By now, the initial Service Worker has been terminated, and the parent
process decides once again to spawn an origin A Service Worker in CP.
5) The Service Worker is spawned in CP, but the call to SetPermissionsWithKey
is a no-op, leaving CP1 with a mismatched value for permission P.
An additional scenario is if the parent process updates a permission during a
remote Service Worker's lifetime.
This patch, which would subscribe CP1 to permission updates when the parent
process knows a Service Worker would be spawned in CP1, prevents these problems.
Differential Revision: https://phabricator.services.mozilla.com/D48620
--HG--
extra : moz-landing-system : lando
The changes are just cleanup for member variables/methods that should
be private to ServiceWorkerManager.
Depends on D48179
Differential Revision: https://phabricator.services.mozilla.com/D48181
--HG--
extra : moz-landing-system : lando
Also replace ServiceWorkerManager shutdown logic's normal for-loops with
range-based for-loops.
Depends on D43170
Differential Revision: https://phabricator.services.mozilla.com/D48179
--HG--
extra : moz-landing-system : lando
- Listen for observer topics in the parent-process when in parent intercept mode
- Remove an extra postMessage call (and the corresponding message handler)
Differential Revision: https://phabricator.services.mozilla.com/D44513
--HG--
extra : moz-landing-system : lando
Skip frequently crashing test on fission (it was already marked as failing).
Differential Revision: https://phabricator.services.mozilla.com/D47694
--HG--
extra : moz-landing-system : lando
Now that we only use a single field of the browser that gets passed in
to isWebRemoteType, I think it makes more sense to just pass in the
remote type directly.
Differential Revision: https://phabricator.services.mozilla.com/D47179
--HG--
extra : moz-landing-system : lando
Dedicated workers should be in the same agent cluster with its parent/creator.
The other workers (ShareWorker/ServiceWorker/ChromeWorker) create another agent
cluster when they are created from the creator.
Differential Revision: https://phabricator.services.mozilla.com/D43241
--HG--
extra : moz-landing-system : lando
ServiceWorker mochitests fail for Fission is fixed by bug 1542415.
Remove the skip-if for tests
Differential Revision: https://phabricator.services.mozilla.com/D46030
--HG--
extra : moz-landing-system : lando
