diff options
author | Moonchild <moonchild@palemoon.org> | 2022-01-30 16:16:39 +0000 |
---|---|---|
committer | Moonchild <moonchild@palemoon.org> | 2022-04-08 20:23:10 +0200 |
commit | 7d49b154e2275701fd5e65ac8990ee45e30bb69d (patch) | |
tree | 19180fd1ae5920bcd7701f32a8b1aaf52856a4a5 | |
parent | d5ae68701b8367841e8e1c994d68e324164ca0ce (diff) | |
download | uxp-7d49b154e2275701fd5e65ac8990ee45e30bb69d.tar.gz |
Issue #1840 - Try to deal with bad website scripting loading/unloading modules.
Apparently Bing does rapid-fire loading/unloading of module scripts that
causes our attempts at resolving and initializing them to end up with
null fetched modules.
Returning null is probably a better way to handle this than crashing
on ms->ModuleRecord() ;-)
-rw-r--r-- | dom/script/ScriptLoader.cpp | 8 |
1 files changed, 8 insertions, 0 deletions
diff --git a/dom/script/ScriptLoader.cpp b/dom/script/ScriptLoader.cpp index f669690ce7..d2c5f5bd59 100644 --- a/dom/script/ScriptLoader.cpp +++ b/dom/script/ScriptLoader.cpp @@ -812,6 +812,10 @@ HostResolveImportedModule(JSContext* aCx, JS::Handle<JSObject*> aModule, if (!string.init(aCx, aSpecifier)) { return nullptr; } + if (!aModule || !aCx) { + // Our module context was ripped out from under us... + return nullptr; + } nsCOMPtr<nsIURI> uri = ResolveModuleSpecifier(script, string); @@ -824,6 +828,10 @@ HostResolveImportedModule(JSContext* aCx, JS::Handle<JSObject*> aModule, ModuleScript* ms = script->Loader()->GetFetchedModule(uri); MOZ_ASSERT(ms, "Resolved module not found in module map"); + if (!ms) { + // Already-resolved module has been removed from the map/unloaded... + return nullptr; + } MOZ_ASSERT(!ms->HasParseError()); MOZ_ASSERT(ms->ModuleRecord()); |