This copies over the behavior for style & subdocument restrictions.
Admittedly, with this if/else spagetthi, it would be preferable to
turn this into restriction levels or lump some of the known-to-be-safe
prefs together, but I would prefer we wait a couple of cycles to
make sure this makes it all the way to release before we refactor.
Differential Revision: https://phabricator.services.mozilla.com/D145306
The relevant information was already being set on the final channel when
not performing a process switch [1], but it was not copied for
cross-process redirects, despite being sent to the child process. This
wasn't a problem previously, as we would handle downloads in the parent
process, but with the download panel improvements, it is an issue.
This issue led to the wrong filename being selected by default when
clicking on the save icon in a downloaded PDF from a blob URL, as the
information was lost before being passed to the pdf.js stream filter.
[1]: https://searchfox.org/mozilla-central/rev/87ecd21d3ca517f8d90e49b32bf042a754ed8f18/netwerk/ipc/DocumentChannelChild.cpp#308-315
Differential Revision: https://phabricator.services.mozilla.com/D145255
This list contains items that contain actual user data like
their device name or their downloads path, items that contain
UUIDs that could be used to track users across different
origins, sessions, or private browsing, and values that
either change occassionally or don't have enough entropy to
serve as a long-lived UUID, but do have enough entropy to be
used as a short-term correlatable identified to e.g.
de-anonymize someone use the VPN feature of containers.
Depends on D145259
Differential Revision: https://phabricator.services.mozilla.com/D145260
During testing I started hitting these cases that were not
well-documented for the person hitting the crash, so let's
improve them.
Differential Revision: https://phabricator.services.mozilla.com/D145259
Virtualenv-based objdir detection doesn't work for instrumented builds,
as instrumentation-specific objdirs aren't created.
Resolve this by:
* Removing redundant cwd-based topsrcdir resolution - the
`__file__`-based code path below covers this case.
* Only using virtualenv-based resolving if topsrcdir isn't resolved.
* Documenting that virtualenv-based resolution is problematic for
instrumented builds.
Differential Revision: https://phabricator.services.mozilla.com/D144030
This is failing frequently, and leaks from webdriver restarting the
browser or whatever probably aren't really important.
Differential Revision: https://phabricator.services.mozilla.com/D145278
When running in a Worker, the canvas2d SetFontInternal method can't call GetFontStyleForServo
because it doesn't have a canvasElement or presShell to pass. But we can use the method
ServoCSSParser::ParseFontShorthandForMatching to parse the canvas 'font' property, if we
extend it so as to also return the size from the font shorthand.
(This is incomplete by itself; Emilio's following patch fixes it up, so the intention is to land them together.)
Depends on D144186
Differential Revision: https://phabricator.services.mozilla.com/D144187
These need to be atomic so that they can be accessed by canvas code when running on a worker thread
without calling main-thread-only Preferences APIs.
Depends on D144185
Differential Revision: https://phabricator.services.mozilla.com/D144186
We don't need to null-check the mCanvasElement and mDocShell members in these methods,
and bail out if neither is provided, because in that case the following GetPresShell() call
will return null and we'll bail out there anyhow.
Removing these extra checks will simplify the changes involved in enabling the canvas code
to be used in a Worker context, where it is not connected to a document.
Depends on D144184
Differential Revision: https://phabricator.services.mozilla.com/D144185
Nothing uses this member, so remove it to make it clear we don't need to provide it
when setting up a CanvasRenderingContext2D.
Differential Revision: https://phabricator.services.mozilla.com/D144184
The patch appears to have caused an increase in timeouts, but based on a
quick scan of the log, it appears it's due to the test running right
against the time limit, rather than due to the test deadlocking or
similar.
Differential Revision: https://phabricator.services.mozilla.com/D145235
Small cleanup: GetBaseURI is one of the methods of a ScriptLoadInterface. This also makes it easier
to split these into files (done separately)
Differential Revision: https://phabricator.services.mozilla.com/D144835
This makes the relationship between these classes and the dom ScriptLoadHandler clearer. Once we
move to ScriptLoadRequests, these three classes will share a loadhandler class which will take care
of script decoding.
Differential Revision: https://phabricator.services.mozilla.com/D145063
Similar to what was done with the prior patch, this can be described as the companion method to
loading from the network in the LoaderListener, with special requirements in terms of how it populates the loaded request
data and updates the WorkerPrivate. At some point, it may make sense to have the service worker loader as a child class of the
main worker loader, but that won't be done here (I hope anyway).
Differential Revision: https://phabricator.services.mozilla.com/D144838
We don't have a correlation to these methods in the ScriptLoadHandler on the DOM side. For now,
rename them to make the difference clear.
Differential Revision: https://phabricator.services.mozilla.com/D144837
The LoaderListener is currently used to forward events to WorkerScriptLoader. It fills a similar
role to the ScriptLoadHandler on the DOM both for OnStartRequest and OnStreamComplete. In the case
of the DOM loader, the responsibility for performing certain channel related tasks is left to the
ScriptLoadHandler, in particular the decoding of the string into UTF8 or UTF16.
While the decoding is embedded in the onStreamCompleteInternal method, it is not a 1:1 mapping.
Some of the responsibilities handled in the `OnStreamCompleteInternal` method are instead handled in
`ScriptLoader::PrepareLoadedRequest`, such as populating the SourceMaps field, managing the channel,
etc are normally handled within the ScriptLoader.
However, in the case of the WorkerScriptLoader we have two paths to reach a completed load:
* from the network
* from the cache
These have different requirements in terms of preparing the loaded request, for example the cache
does not forward a SourceMap.
In the interest of not complicating things too much, for now the method is moved wholesale into
LoaderListener. In a separate PR I will handle renaming. The next step will be to do a similar move
for the CacheScriptLoader.
Differential Revision: https://phabricator.services.mozilla.com/D144836
This just brings us a bit closer to the DOM pattern of Script Loading. One difference is that we
evaluate a source buffer instead of a JSScript, so rather than "Execute", we will still ahandle data
using "Evaluate". Maybe later we can make these two methods on the SpiderMonkey side a bit more
descriptive. For now this gets us pretty close to the goal of "if you know the DOM script loader, you know the
Worker Script loader" and vice-versa.
Differential Revision: https://phabricator.services.mozilla.com/D145065
This is mostly to bring us in line with the naming of everything else, and also make it clear that
we are crossing a thread boundary.
Differential Revision: https://phabricator.services.mozilla.com/D144990
Continuation of integrating methods from the ScriptExecutorRunnable into the WorkerScriptLoader. In this
case, the primarily function being moved here is the batch evaluation of scripts. This roughly
aligns with the ProcessPendingRequests. The function has been renamed to reflect the similarity of
responsibilities between the two classes.
As a driveby change -- the prerun function now only has one responsibility, and it is related to
loading so this has been moved and named.
Differential Revision: https://phabricator.services.mozilla.com/D144961
Part 1 of integrating the operations that the ScriptExecutorRunnable was doing on the
WorkerScriptLoader into the WorkerScriptLoader itself. This first pass moves some of the smaller,
contained functions over to the WorkerScriptLoader: The shutdown, evaluate and logging methods.
Differential Revision: https://phabricator.services.mozilla.com/D144327
This encompasses the dispatching of the loader runnable as part of the api of WorkerScriptLoader.
The same pattern will be used for the ScriptExecutorRunnable. We might be able to just use an NS
runnable method instead here, if that is preferred.
Differential Revision: https://phabricator.services.mozilla.com/D144991
We are gradually moving closer towards a ScriptLoader implementation based on the DOM ScriptLoader.
The patch is done in three parts:
* WorkerScriptLoader adjustments (WSL Parts 1-6)
* LoaderHandler class adjustments (LoadHandler Parts 1-4)
* Cleanups
The class ScriptLoaderRunnable was being passed between runnables to access information
that was shared. That role will now be done by the WorkerScriptLoader which will eventually inherit
from ScriptLoaderInterface. This is the basis for building up the Module Loader implementation for
workers. This first patch splits the responsibility of the runnable and the data holding class.
In the next few patches, methods from the ScriptExecutorRunnable will also be moved into this class,
and the runnables themselves will no longer hold execution information. Instead, they will be used
as dispatchers to have the work run in the correct place. In the next step, the same pattern will be
done with the ScriptExecutorRunnable.
Differential Revision: https://phabricator.services.mozilla.com/D144326
