The initial problem reported in the bug is that we try to speculatively load a
bareword import before the import map is dynamically inserted that makes that
load valid. The load fails and then we cache the failure in the module map.
The more general problem is that import maps change the locations that imports
are resolved to so if when there is a dynamically inserted import map
speculative preload may load and cache the wrong things.
This patch fixes this problem by removing any preloaded modules from the module
map when an import map is registered.
Previously we used to do something like this but it was changed because I
wasn't confident that it wouldn't remove too much. However it appears that this
is necessary to handle this situation, so it's implemented here but with more
checks that it only removes preloaded modules. This is handled by adding extra
flags where necessary so we have the information on hand to check.
I've made these diagnostic asserts so that this actually gets check in real use.
Differential Revision: https://phabricator.services.mozilla.com/D202611
The initial problem reported in the bug is that we try to speculatively load a
bareword import before the import map is dynamically inserted that makes that
load valid. The load fails and then we cache the failure in the module map.
The more general problem is that import maps change the locations that imports
are resolved to so if when there is a dynamically inserted import map
speculative preload may load and cache the wrong things.
This patch fixes this problem by removing any preloaded modules from the module
map when an import map is registered.
Previously we used to do something like this but it was changed because I
wasn't confident that it wouldn't remove too much. However it appears that this
is necessary to handle this situation, so it's implemented here but with more
checks that it only removes preloaded modules. This is handled by adding extra
flags where necessary so we have the information on hand to check.
I've made these diagnostic asserts so that this actually gets check in real use.
Differential Revision: https://phabricator.services.mozilla.com/D202611
The initial problem reported in the bug is that we try to speculatively load a
bareword import before the import map is dynamically inserted that makes that
load valid. The load fails and then we cache the failure in the module map.
The more general problem is that import maps change the locations that imports
are resolved to so if when there is a dynamically inserted import map
speculative preload may load and cache the wrong things.
This patch fixes this problem by removing any preloaded modules from the module
map when an import map is registered.
Previously we used to do something like this but it was changed because I
wasn't confident that it wouldn't remove too much. However it appears that this
is necessary to handle this situation, so it's implemented here but with more
checks that it only removes preloaded modules. This is handled by adding extra
flags where necessary so we have the information on hand to check.
I've made these diagnostic asserts so that this actually gets check in real use.
Differential Revision: https://phabricator.services.mozilla.com/D202611
Also fix opSetScriptLineAndColumnNumberAndFreeze::mColumnNumber to point the
first character of the script source, instead of '>' of the start tag.
Differential Revision: https://phabricator.services.mozilla.com/D193374
Also fix opSetScriptLineAndColumnNumberAndFreeze::mColumnNumber to point the
first character of the script source, instead of '>' of the start tag.
Differential Revision: https://phabricator.services.mozilla.com/D193374
The main change in this patch is to prevent access to main-thread objects
while off-thread. This is done by using nsMainThreadPtrHandle to wrap main
thread pointers in the runnable. This prevents access to their targets when
off thread and ensure they are only released on the main thread.
This means that mRunnable is now only accessed on the main thread and so it
doesn't need to be atomic and can be a normal RefPtr. We also don't need to
leak a reference to it in AttemptOffThreadScriptCompile.
This also requires that timing data is moved to the runnable.
Cancellation should always have happened by unlink or destruction of
ScriptLoadContext so handling for that is removed.
Differential Revision: https://phabricator.services.mozilla.com/D166667
The main change in this patch is to prevent access to main-thread objects
while off-thread. This is done by using nsMainThreadPtrHandle to wrap main
thread pointers in the runnable. This prevents access to their targets when
off thread and ensure they are only released on the main thread.
This means that mRunnable is now only accessed on the main thread and so it
doesn't need to be atomic and can be a normal RefPtr. We also don't need to
leak a reference to it in AttemptOffThreadScriptCompile.
This also requires that timing data is moved to the runnable.
Cancellation should always have happened by unlink or destruction of
ScriptLoadContext so handling for that is removed.
Differential Revision: https://phabricator.services.mozilla.com/D166667
In order to use the WorkerLoadContext as a handle for ScriptLoadRequests in the main thread portion
of worker loading, we need to make it thread safe. Which means, it cannot be CC'd, and we need to
manually break cycles. This patch does the first portion of this work, which is inroduce two new
loadContextBase classes, that are either cc'd or not cc'd. For the DOM and mozJSComponent loader, we
continue to use a CC'd LoadContextBase. Workers however now have a non-cc'd variant.
Differential Revision: https://phabricator.services.mozilla.com/D160333
