This introduces the basic skeleton to make WorkerScriptLoader a ScriptLoaderInterface.
ScriptLoaderInterface defines the methods that are shared between any given ScriptLoader (for
example the DOM script loader, the ComponentScriptLoader) and the ModuleLoader for a particular
component.
This patch also adds documentation to make the role and responsibilities of the
ScriptLoaderInterface clear.
Depends on D147321
Differential Revision: https://phabricator.services.mozilla.com/D147313
This will be used by child modules. This is currently not used, but it will be in modules. I can
move this over to the other bug, if necessary.
Depends on D147325
Differential Revision: https://phabricator.services.mozilla.com/D147321
This brings back the behavior to iterated over all of the load requests to cancel the cache
promise. I tried a couple of different ways of doing this, including deleting the cache, but this
seemed to be the cleanest way.
Depends on D147322
Differential Revision: https://phabricator.services.mozilla.com/D154382
This moves the shutdown operations out of the ScriptExecutorRunnable, and into something that can be
called independent. This does not change the behavior in this case, however it is important for
modules, which will have promises that resolve after the ScriptExecutorRunnable has closed.
Depends on D155231
Differential Revision: https://phabricator.services.mozilla.com/D147322
This enables us to send files to load that are not part of our executing scripts list. This unlocks
the ability to send single module scripts to be loaded without executing them. It also gives
us a way to get the list of files that are to be loaded.
Depends on D147318
Differential Revision: https://phabricator.services.mozilla.com/D155231
This will be used by child modules. This is currently not used, but it will be in modules. I can
move this over to the other bug, if necessary.
Depends on D147325
Differential Revision: https://phabricator.services.mozilla.com/D147321
This brings back the behavior to iterated over all of the load requests to cancel the cache
promise. I tried a couple of different ways of doing this, including deleting the cache, but this
seemed to be the cleanest way.
Depends on D147322
Differential Revision: https://phabricator.services.mozilla.com/D154382
This moves the shutdown operations out of the ScriptExecutorRunnable, and into something that can be
called independent. This does not change the behavior in this case, however it is important for
modules, which will have promises that resolve after the ScriptExecutorRunnable has closed.
Depends on D155231
Differential Revision: https://phabricator.services.mozilla.com/D147322
This enables us to send files to load that are not part of our executing scripts list. This unlocks
the ability to send single module scripts to be loaded without executing them. It also gives
us a way to get the list of files that are to be loaded.
Depends on D147318
Differential Revision: https://phabricator.services.mozilla.com/D155231
Previously, we had the client info for main scripts on the ScriptLoadInfo, and in the ScriptLoader
for non-main scripts (ImportScripts case). This was a bit confusing, so I moved it all to the ScriptLoader as in the
importScripts case, it is always recreated with each new load. However, for modules this is not
true. In order to make it persistant for main scripts and modules, as well as ensure that it has the
correct data, it should always live on the WorkerLoadContext.
Differential Revision: https://phabricator.services.mozilla.com/D147317
This implements the core of the change -- which is implementing an explicit IsTopLevel flag for
`WorkerLoadContexts`, and removing `mIsMainScript` from the loader. I've asked for some
clarification on this part of the spec from the whatwg editors, as I think this may be misnamed. It
is likely that what is meant here is `IsInitialScript` rather than `IsTopLevel` -- as there is a
note stating that this should be initialized with the agent cluster. Once this is clarified I may
update the name.
Differential Revision: https://phabricator.services.mozilla.com/D147319
Cleanup, optional. It seems strange to have two ways to access the WorkerPrivate, and
ThreadSafeWorkerRef seems like the more reasonable choice.
Differential Revision: https://phabricator.services.mozilla.com/D154383
This addresses part of the issue, by holding a strong ref until we shutdown, so that we do not end
up in a situation where the worker closes before we finish cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D154381
Here we split ScriptLoadInfo's representation -- we are distinguishing between "what is being loaded"
and "how it is being loaded in a worker context". Requesting review from asuth for the workers side
of things, and jonco for js/loader.
Differential Revision: https://phabricator.services.mozilla.com/D146175
This section of the patch queue starts the migration from ScriptLoadInfo to
ScriptLoadRequest/LoadContext pairs.
We will be making use of the ModuleLoader, and in the future we will have a unified ScriptLoader
implementation (currently, the skeleton for this is in ScriptLoaderInterface). ScriptLoadRequest has
been rewritten to be generic to all contexts, with a companion object "LoadContext" that will handle
specialized behavior required to load the request. That is exactly the case we have with workers,
most of the fields are generic with a couple of specialized fields associated with service workers.
Quick itemization of what will happen
* Patches 1-5: Focuses on getting things into place without using them, we rely on
ScriptLoadInfo (later renamed to WorkerLoadContext).
* Patches 6-7: This is a refactoring of what will be a shared data structure for decoding scripts.
As we will be using requests, we can use this pretty much in the form it exists in on the DOM, and
this cleanup makes it a bit nicer for the DOM as well (in my opinion anyway).
* Patches 8-12: We migrate all shared data to the standard utilization used by other loaders (DOM
and component loader). The biggest pieces is `.mScriptData` transitioning from a stream of bits
that haven't been decoded, to a decoded source text that can be used directly. This was enabled by
patches 6-7.
* The final patches are small cleanups and documentation.
Differential Revision: https://phabricator.services.mozilla.com/D146173
This step is not strictly necessary, and if this is too ugly we can think of something else. The
reason for this change is that ScriptLoadRequests are initialized by a URI, and the owner of these
objects will be the worker thread. However, the current strategy requires that we create the URI
only on the main thread. We always have this information however, when we create the loader, so
there isn't any reason to defer this step until we bounce back into the main thread.
This is another spot where we can reduce reliance on the main thread, which is an eventual goal, so
it seems like this change is an improvement even outside of the goal of moving to ScriptLoadRequests
as a representation.
An alternative approach here would be to initialized the nsIURI ahead of time, and pass it with the
script url to the initialization of the WorkerScriptLoader. However, this isn't ideal as _ideally_
we would remove the text url all together, but this is necessary for errors. We can do this if we
handle workers and main thread differently (and maybe it is worthwhile) as only the main thread
needs encoding information.
Differential Revision: https://phabricator.services.mozilla.com/D146170
Cleanup: tracking if the scripts have been executed can
now be done on the worker side without information from the main thread. This also introduces a name
change: We are really interested in whether the scripts are all totally finished whatever they were
doing, not if they are ready to be run.
Differential Revision: https://phabricator.services.mozilla.com/D145450
This is the last piece that we need in order to move ahead with managing the lists by the worker
thread. This patch moves the last iteration over mLoadingRequests over to the worker thread.
Differential Revision: https://phabricator.services.mozilla.com/D145449
This follows up the cancellation requirements -- CacheCreator is a main thread only datastructure,
which must be cleaned up once the last ScriptLoadInfo is dispatched. Previously, we determined this
via iteration. Now, we manage it as part of ScriptLoadInfo, and release our reference to it when we
dispatch a given ScriptLoadInfo. Later, once we transition to ScriptLoadRequest and LoadContexts,
the cache information can live on a ServiceWorkerLoadContext[1]. This will help use differentiate
between regular worker loader environments and service worker environments.
[1]: https://searchfox.org/mozilla-central/rev/997a56b018662e2940c99bbaf57a6ac9d1aa5422/js/loader/LoadContextBase.h#22-34
Differential Revision: https://phabricator.services.mozilla.com/D145448
The joys of multi-threaded programming:
As you likely noticed, we now have list modification where previously we didn't.
We need move all list modification on the worker side, not the main thread side.
The only reason this isn't showing up on thread sanitizer now, is because the main
thread is acting as the owner of the the lists.
In order to implement Worker ownership, we need to remove all list traversal from the main thread
runnable. There are two significant cases in which we traverse lists: Cancellation, and Dispatching.
Here we handle part of the story for cancellation.
The strategy we take is fundamentally the same as in the DOM Script Loader -- We use the
"mCanceledMainThread" flag to indicate to our load handlers that the thread has been cancelled.
This is taken directly from the DOM loader [1] approach.
[1]: https://searchfox.org/mozilla-central/rev/997a56b018662e2940c99bbaf57a6ac9d1aa5422/dom/script/ScriptLoadHandler.cpp#128-132
Differential Revision: https://phabricator.services.mozilla.com/D145446
Much like Part 2, we are replacing the prior Span structure with a list of pointers. This also
reflects the ultimate ScriptLoadRequestList implementation: We will be modifying lists, moving the
head of one list to the tail of the other, in order to preserve the ImportScripts invariant around
post order == evaluation order.
Differential Revision: https://phabricator.services.mozilla.com/D145443
This patch introduces a temporary array for the purposes of this refactoring. First, I'll
demonstrate the new loading strategy using the nsTArray datastructure, before moving everything over
to a ScriptLoadRequestList and ScriptLoadRequest datastructure. The impact of this change will only
exist for the course of this bug.
Differential Revision: https://phabricator.services.mozilla.com/D145442
The goal of this patch stack is to transition from using the ScriptLoadInfo to represent script
requests for workers, to ScriptLoadRequest and its partner datastructure ScriptLoadRequestList.
There are a number of differences between these two datastructures, but they fundamentally represent
the same thing: a request which is either about to be loaded, or about to be executed.
To get there, in a reasonable manner, is a bit tricky. ScriptLoadRequest et all are refcounted, and
restrict which thread can delete or add them. The decision I've made in this transformation is to
make the Worker thread the home of ScriptLoadRequests. This means that we have to change how we are
doing things on the WorkerScriptLoader so that the MainThread is largely unaware of the
ScriptLoadRequestList, and it only operates in terms of ScriptLoadRequests (or, ScriptLoadInfos as
they are known for now)
The following need to be changed:
* We need to prepare everything to operate on pointers (Prep Patches 1-3)
* Cancellation must no longer iterate over a list (Prep patches 4-8, removing the mChannel reference
is a bonus)
* List management must only be done on the Worker side (Prep Patches 9-10)
This first patch transitions from using the ScriptLoadInfo directly to passing around references.
You will find a similar explaination for the actual transition in the patches that follow the prep
patches. This is bundled in the same bug as the goal here remains the same.
Differential Revision: https://phabricator.services.mozilla.com/D145441
This attempts to make a difference between "true" private classes and ones accessed by friends (even
though friends can get at private members...)
Differential Revision: https://phabricator.services.mozilla.com/D145088
This patch queue splits up dom/workers/ScriptLoader.cpp into several files, with the goal of better
readability and improved comprehension of the relationships between the classes in question. Classes
that can be treated as "intrinsic" to the ScriptLoader (such as the private runnables
ScriptLoaderRunnable and ScriptExecutorRunnable) will remain in ScriptLoader.cpp, as will functions
and classes that currently make up the interface of this file (ChannelGetterRunnable,
ChannelFromScriptURL{MainThread,WorkerThread}). All other classes will be moved out and put under a
`workerinternals::loader` namespace because I couldn't think of anything better.
However, for this first patch: We are moving ScriptLoadInfo to a mozilla::dom level. This is because
this class will play the same role as ScriptLoadContext[1], but for workers.
[1]: https://searchfox.org/mozilla-central/rev/997a56b018662e2940c99bbaf57a6ac9d1aa5422/dom/script/ScriptLoadContext.h
Differential Revision: https://phabricator.services.mozilla.com/D144839
- Worker debugger globals gets a client with a null principal
- Ensure globals are created before script loads
- Introduce WorkerGlobalScopeBase to share code
- Transfer ClientSource ownership from WorkerPrivate to worker globals
- Require getting clients from the globals instead of WorkerPrivate with the
exception of getting the reserved client before the non-debugger global is
created
Differential Revision: https://phabricator.services.mozilla.com/D68936
Given that we are going to add ContentBlockingAllowList in
CookieSettings, so CookieSettings will be responsible for more stuff than the
cookie behavior and cookie permission. We should use a proper name to
reflect the purpose of it. The name 'CookieSettings' is misleading that
this is only for cookie related stuff. So, we decide to rename
'CookieSettins' to 'CookieJarSettings' which serves better meaning here.
Differential Revision: https://phabricator.services.mozilla.com/D63935
--HG--
rename : netwerk/cookie/CookieSettings.cpp => netwerk/cookie/CookieJarSettings.cpp
rename : netwerk/cookie/nsICookieSettings.idl => netwerk/cookie/nsICookieJarSettings.idl
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
Iulian Moraru
Yulia Startsev
Jens Stutte
Cosmin Sabou
Noemi Erli
Butkovits Atila
Simon Giesecke
Perry Jiang
Tim Huang
Gabriele Svelto