When a preload request is used, it might be being compiled off-thread.
Currently this is handled for defer and async requests in AddDeferRequest and
AddAsyncRequest but not for XSLT or other kinds of requests. The patch handles
this whenever we use a preload request.
I don't know for sure that this is what's causing the crash but it seems likely
given the assertion.
Depends on D120072
Differential Revision: https://phabricator.services.mozilla.com/D120073
The original patch had caused some assertions so I rewrote it. This now puts
all untracked top-level requests on the new list while they are being compiled
so handles preload requests too.
Differential Revision: https://phabricator.services.mozilla.com/D119386
There are parse tasks present when the JS engine is being shut down that have
finished but haven't had their results collected by the embedding. This
shouldn't happen, and I think it's happening here because we're leaking a
JSRuntime (we cancel these when we shut down a runtime).
There's a comment that says this isn't necessary but cancelling outstanding
compile requests in ScriptLoader::Destroy fixes this problem on try. I don't
understand well enough to know what's going wrong with the current approach but
this fixes both the crash and the leak.
Differential Revision: https://phabricator.services.mozilla.com/D119315
There are parse tasks present when the JS engine is being shut down that have
finished but haven't had their results collected by the embedding. This
shouldn't happen, and I think it's happening here because we're leaking a
JSRuntime (we cancel these when we shut down a runtime).
There's a comment that says this isn't necessary but cancelling outstanding
compile requests in ScriptLoader::Destroy fixes this problem on try. I don't
understand well enough to know what's going wrong with the current approach but
this fixes both the crash and the leak.
Differential Revision: https://phabricator.services.mozilla.com/D119315
Replace JS pageload proportion probes with absolute time measurements and add new probes to measure GC and main thread parsing impact during page load.
Differential Revision: https://phabricator.services.mozilla.com/D114388
Firstly we need to find a usable ScriptLoader for code in the content script sandbox,
for that we use the normal ScriptLoader associated with DOMWindow wrapped by the sandbox.
Secondly we need to execute the module in the global of the sandbox instead of the
"ScriptGlobal" the ScriptLoader is actually associated with. The main
behavior change here comes from using xpc::NativeGlobal in HostImportModuleDynamically
and passing that global around inside ScriptFetchOptions.
To ensure that content-scripts and the webpage don't share imported modules,
the module map (mFetchingModules and mFetchedModules) now uses a complex key
of <URI, Global>. The Global is a nullptr for normal imports from a webpage.
Differential Revision: https://phabricator.services.mozilla.com/D107076
Firstly we need to find a usable ScriptLoader for code in the content script sandbox,
for that we use the normal ScriptLoader associated with DOMWindow wrapped by the sandbox.
Secondly we need to execute the module in the global of the sandbox instead of the
"ScriptGlobal" the ScriptLoader is actually associated with. The main
behavior change here comes from using xpc::NativeGlobal in HostImportModuleDynamically
and passing that global around inside ScriptFetchOptions.
To ensure that content-scripts and the webpage don't share imported modules,
the module map (mFetchingModules and mFetchedModules) now uses a complex key
of <URI, Global>. The Global is a nullptr for normal imports from a webpage.
Differential Revision: https://phabricator.services.mozilla.com/D107076
Firstly we need to find a usable ScriptLoader for code in the content script sandbox,
for that we use the normal ScriptLoader associated with DOMWindow wrapped by the sandbox.
Secondly we need to execute the module in the global of the sandbox instead of the
"ScriptGlobal" the ScriptLoader is actually associated with. The main
behavior change here comes from using xpc::NativeGlobal in HostImportModuleDynamically
and passing that global around inside ScriptFetchOptions.
To ensure that content-scripts and the webpage don't share imported modules,
the module map (mFetchingModules and mFetchedModules) now uses a complex key
of <URI, Global>. The Global is a nullptr for normal imports from a webpage.
Differential Revision: https://phabricator.services.mozilla.com/D107076
Previously, the DocGroup type was not cycle-collected, as it needed to have
references from other threads for Quantum DOM. Nowadays the only off-main-thread
use of DocGroup is for dispatching runnables to the main thread which should be
tracked using a performance counter for about:performance. This means we can
remove the DocGroup references from these dispatching callsites, only storing
the Performance Counter we're interested in, and simplify make DocGroup be
cycle-collected itself.
This fixes a leak caused by adding the WindowGlobalChild getter to
WindowContext, by allowing cycles between the document and its BrowsingContext
to be broken by the cycle-collector.
Differential Revision: https://phabricator.services.mozilla.com/D108865
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
Instead of using both an optional out-param and a boolean return value, we
can simply return the token directly. This is less error-prone and requires
no change to callers that did not use the out-param.
Differential Revision: https://phabricator.services.mozilla.com/D101654
The `category.WithOptions(...)` syntax was a bit strange and difficult to explain.
Now the category and options are separate parameters. Default options can be specified with `MarkerOptions{}` or just `{}`.
As a special case, defaulted-NoPayload functions don't need `<>`, and defaulted-NoPayload functions and macros don't even need `{}` for default options, e.g.:
`profiler_add_marker("name", OTHER); PROFILER_MARKER_UNTYPED("name", OTHER);`
Differential Revision: https://phabricator.services.mozilla.com/D91680
The `category.WithOptions(...)` syntax was a bit strange and difficult to explain.
Now the category and options are separate parameters. Default options can be specified with `MarkerOptions{}` or just `{}`.
As a special case, defaulted-NoPayload functions don't need `<>`, and defaulted-NoPayload functions and macros don't even need `{}` for default options, e.g.:
`profiler_add_marker("name", OTHER); PROFILER_MARKER_UNTYPED("name", OTHER);`
Differential Revision: https://phabricator.services.mozilla.com/D91680
The name `AUTO_PROFILER_MARKER_TEXT` is more consistent with the equivalent non-`AUTO` macro, and similarly arguments have been re-ordered to be the same, i.e.: Name, category&options, text.
The different macros with different argument sets can now be collapsed into one macro, and the optional arguments (timing, inner window id, backtrace) can easily be added to the `MarkerOptions` where needed.
As a bonus, a specific start time can optionally be provided at construction time.
Differential Revision: https://phabricator.services.mozilla.com/D89588
Add a safety check before appending a request to the bytecode cache queue to see if it already exists in another list.
Differential Revision: https://phabricator.services.mozilla.com/D88984
The problem is that ResolveModuleSpecifier is being passed a null script and is falling back to using the document base URL to resolve the module import (which is the correct thing to do in some cases). This is happening because the referring JS script was not assoicated with a loader script when it was loaded since it came from the bytecode cache and the logic to do that is missing on this path.
Differential Revision: https://phabricator.services.mozilla.com/D86352
`ReadyToExecuteParserBlockingScripts` was walking the ancestor chain but
would stop if it hit an OOP ancestor. With this change we walk the
`WindowContext` tree instead, so that we may skip over OOP ancestors
and continue checking all in process ancestors.
Differential Revision: https://phabricator.services.mozilla.com/D86436
Previously this used |cx->isExceptionPending()| to determine whether the import had succeeded, which doesn't work if there was an uncatchable exception. The patch changes this to pass an explicit status.
Differential Revision: https://phabricator.services.mozilla.com/D85856
