This member was never changed after it was set, but it couldn't be const
because WorkerLoadInfo used a custom StealFrom() function instead of an
idiomatic move constructor and move assignment operator. This commit
replaces StealFrom with its idiomatic counterparts, adds a function that
determines a new worker's secure context status, and uses that function
to initialize the now const mIsSecureContext.
Making constant members const is part of a greater effort to ensure that
data is either modified from a single thread only, or access to it is
synchronized properly.
Differential Revision: https://phabricator.services.mozilla.com/D12030
--HG--
extra : moz-landing-system : lando
We only need to expose an intercept controller in SharedWorkers if we're on
the non-parent-intercept version of ServiceWorkers or if e10s is off.
nsDocShell already does this dance and we have to mirror it.
Differential Revision: https://phabricator.services.mozilla.com/D12490
--HG--
extra : moz-landing-system : lando
Add some memory usage information to the Performance counters and make everything asynchronous.
Differential Revision: https://phabricator.services.mozilla.com/D7984
--HG--
extra : moz-landing-system : lando
This member was never changed after it was set, but it couldn't be const
because WorkerLoadInfo used a custom StealFrom() function instead of an
idiomatic move constructor and move assignment operator. This commit
replaces StealFrom with its idiomatic counterparts, adds a function that
determines a new worker's secure context status, and uses that function
to initialize the now const mIsSecureContext.
Making constant members const is part of a greater effort to ensure that
data is either modified from a single thread only, or access to it is
synchronized properly.
Differential Revision: https://phabricator.services.mozilla.com/D12030
--HG--
extra : moz-landing-system : lando
In the next patch I get rid of the duplicated arguments.
Differential Revision: https://phabricator.services.mozilla.com/D11826
--HG--
extra : rebase_source : 2c21364406b9a757a78ae523e212a180f848ff9b
In order to fix the problem mentioned in comment 91 & co, we need to hold onto
the URI object that we resolve in the child process when we construct the
SharedWorker. Otherwise, we risk the Blob getting deallocated from under us.
This patch isn't sufficient to fix that problem, however, because the worker
code itself ends up going back through strings. I fix that in the next couple
of patches.
Differential Revision: https://phabricator.services.mozilla.com/D11825
--HG--
extra : rebase_source : c77854f00c0d7a102e73e0c81f59cc217f43fd69
This separates out the parent process from the list of child processes and
makes our handling of non-e10s more explicit.
Differential Revision: https://phabricator.services.mozilla.com/D11824
--HG--
extra : rebase_source : 3d4a5c5b427a5ad709468b4063793cb7bce27117
This implements the behavior that as long as there's one non-frozen or
non-suspended actor, we resume or thaw the manager.
Differential Revision: https://phabricator.services.mozilla.com/D11822
--HG--
extra : rebase_source : d5dd0e87581c94b383f1e155b03f63398b2a14a7
It's possible for RuntimeService to be created after 'xpcom-shutdown' has fired. In this case, it
will receive 'xpcom-shutdown-threads' and perform Cleanup() but not Shutdown(). This means that
mShuttingDown will not be set to 'true', but mIdleThreadTimer will be destroyed. This can cause
crashes if a NoteIdleThread callback runs after Cleanup(). This has been observed to happen in
xpcshell tests.
I think the easiest way to handle this is to manually call Shutdown() in Cleanup() when we
see that mShuttingDown == false. This means that Shutdown() might be called in GetOrCreateService()
if we fail to create the service, but it looks like the code can handle this.
Differential Revision: https://phabricator.services.mozilla.com/D10288
--HG--
extra : source : e28fa79bc2f94ca3b72456b47353f2e2dda8da1a
extra : amend_source : f09508b5c62fb1fe4b5997f822b5d4e5f7ef8076
It's possible for RuntimeService to be created after 'xpcom-shutdown' has fired. In this case, it
will receive 'xpcom-shutdown-threads' and perform Cleanup() but not Shutdown(). This means that
mShuttingDown will not be set to 'true', but mIdleThreadTimer will be destroyed. This can cause
crashes if a NoteIdleThread callback runs after Cleanup(). This has been observed to happen in
xpcshell tests.
I think the easiest way to handle this is to manually call Shutdown() in Cleanup() when we
see that mShuttingDown == false. This means that Shutdown() might be called in GetOrCreateService()
if we fail to create the service, but it looks like the code can handle this.
Differential Revision: https://phabricator.services.mozilla.com/D10288
--HG--
extra : rebase_source : 3c4a9cb76b81c4aef87b6373548e9da8ca64075e
extra : amend_source : d17d7a0e35e8bd9fcfbbd567e387d9af857bfd8a
In this patch, I went through any place in DOM fetch code, where there are
ReadableStreams and update the locked, disturbed, readable checks.
Because we expose streams more often, we need an extra care in the use of
ErrorResult objects. JS streams can now throw exceptions and we need to handle
them.
This patch also fixes a bug in FileStreamReader::CloseAndRelease() which could
be called in case mReader creation fails.
- Make ServiceWorkerGlobalScope.importScripts() throw a NetworkError when receiving a
bad (i.e. non-JavaScript) MIME type
- Correct registration-tests-mime-types.js to expect TypeError when registering
a service worker that calls importScripts() with a bad MIME type, per spec
- Add WPT import-scripts-mime-types.https.html to test importScripts success/failure,
depending on MIME type
Depends on D6416
Differential Revision: https://phabricator.services.mozilla.com/D9886
--HG--
extra : moz-landing-system : lando
Remove WorkerPrivate::mQueuedRunnables and its associated functions. The
approach they implement can never be correct, as the parent window gets
'resumed' whenever the debugger resumes execution after a breakpoint. The
interrupted JavaScript invocation has not yet completed, so it is not yet time
to run mQueuedRunnables. Simply re-enqueing them at that point can cause
messages from the worker to arrive out of order.
Instead, we create a separate ThrottledEventQueue,
WorkerPrivate::mMainThreadDebuggeeEventTarget especially for
WorkerDebuggeeRunnables, runnables sent from the worker to the main thread that
should not be delivered to a paused or frozen content window. This queue is
paused and resumed by WorkerPrivate::Freeze, WorkerPrivate::Thaw,
WorkerPrivate::ParentWindowPaused, and WorkerPrivate::ParentWindowResumed.
Since this affects when WorkerDebuggeeRunnables are delivered relative to other
administrative worker runnables, WorkerDebuggeeRunnable must use a
ThreadSafeWorkerRef to ensure that the WorkerPrivate sticks around long enough
for them to run properly.
Depends on D9219
Differential Revision: https://phabricator.services.mozilla.com/D9220
--HG--
extra : moz-landing-system : lando
Jeff Walden
Andrea Marchesini
Yaron Tausky
Blake Kaplan
Razvan Maries
Tarek Ziadé
Sebastian Hengst
Luke Wagner
Jason Orendorff
Gerald Squelart
Daniel Varga
Ryan Hunt
Margareta Eliza Balazs
Ciure Andrei
Ehsan Akhgari
Gurzau Raul
Perry Jiang
Dorel Luca
Jim Blandy