2018794 - High frequency Assertion failure: moduleScript == existingEntry.Data(), at /builds/worker/checkouts/gecko/js/loader/ModuleLoaderBase.cpp:X

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect, P5)

Description

[Treeherder Bug Filer]

Filed by: smolnar [at] mozilla.com
Parsed log: https://treeherder.mozilla.org/logviewer?job_id=550342160&repo=autoland&task=L5cSsBtuREyRCt1HCXTO6Q.0
Full log: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/L5cSsBtuREyRCt1HCXTO6Q/runs/0/artifacts/public/logs/live_backing.log

---

INFO - TEST-START | browser/components/urlbar/tests/browser/browser_switchTab_override.js
[task 2026-02-23T22:32:02.066+00:00] 22:32:02     INFO - GECKO(1500) | [Child 15015: Main Thread]: I/DocShellAndDOMWindowLeak ++DOCSHELL 7f0dd254c800 == 1 [pid = 15015] [id = 0]
[task 2026-02-23T22:32:02.067+00:00] 22:32:02     INFO - GECKO(1500) | [Child 15015: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 1 (7f0dd2584100) [pid = 15015] [serial = 1] [outer = 0]
[task 2026-02-23T22:32:02.068+00:00] 22:32:02     INFO - GECKO(1500) | [Child 15015: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 2 (7f0de6fa9f00) [pid = 15015] [serial = 2] [outer = 7f0dd2584100]
[task 2026-02-23T22:32:02.097+00:00] 22:32:02     INFO - GECKO(1500) | [Parent 1500, Main Thread] WARNING: NS_ENSURE_TRUE(she && she->mInfo->mSharedState.Get()) failed: file /builds/worker/checkouts/gecko/docshell/shistory/SessionHistoryEntry.cpp:1221
[task 2026-02-23T22:32:02.118+00:00] 22:32:02     INFO - GECKO(1500) | [Parent 1500, sqldb:places.sqlite #4] WARNING: Suboptimal indexes for the SQL statement 0x7f5c29273480 (http://mzl.la/1FuID0j).: file /builds/worker/checkouts/gecko/storage/mozStoragePrivateHelpers.cpp:114
[task 2026-02-23T22:32:02.119+00:00] 22:32:02     INFO - GECKO(1500) | [Child 15015: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 3 (7f0dcdd3db00) [pid = 15015] [serial = 3] [outer = 7f0dd2584100]
[task 2026-02-23T22:32:02.169+00:00] 22:32:02     INFO - GECKO(1500) | [Child 1641: Main Thread]: I/DocShellAndDOMWindowLeak ++DOCSHELL 7f0dd253e800 == 2 [pid = 1641] [id = 303]
[task 2026-02-23T22:32:02.169+00:00] 22:32:02     INFO - GECKO(1500) | [Child 1641: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 7 (7f0dcddeea00) [pid = 1641] [serial = 669] [outer = 0]
[task 2026-02-23T22:32:02.170+00:00] 22:32:02     INFO - GECKO(1500) | [Child 1641: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 8 (7f0dcc75e100) [pid = 1641] [serial = 670] [outer = 7f0dcddeea00]
[task 2026-02-23T22:32:02.216+00:00] 22:32:02     INFO - GECKO(1500) | [Parent 1500, Main Thread] WARNING: NS_ENSURE_TRUE(she && she->mInfo->mSharedState.Get()) failed: file /builds/worker/checkouts/gecko/docshell/shistory/SessionHistoryEntry.cpp:1221
[task 2026-02-23T22:32:02.300+00:00] 22:32:02     INFO - GECKO(1500) | [Parent 1500, Main Thread] WARNING: '!mOwner', file /builds/worker/checkouts/gecko/dom/events/Event.cpp:828
[task 2026-02-23T22:32:02.327+00:00] 22:32:02     INFO - GECKO(1500) | [Parent 1500: Main Thread]: I/DocShellAndDOMWindowLeak --DOCSHELL 7f5c1967b800 == 15 [pid = 1500] [id = 400] [url = about:blank]
[task 2026-02-23T22:32:02.332+00:00] 22:32:02     INFO - GECKO(1500) | ### XPCOM_MEM_BLOAT_LOG defined -- logging bloat/leaks to /tmp/tmppt9k87je.mozrunner/runtests_leaks_tab_pid15076.log
[task 2026-02-23T22:32:02.345+00:00] 22:32:02     INFO - GECKO(1500) | [Parent 1500: Main Thread]: I/DocShellAndDOMWindowLeak --DOMWINDOW == 47 (7f5c08556c00) [pid = 1500] [serial = 932] [outer = 0] [url = about:blank]
[task 2026-02-23T22:32:02.346+00:00] 22:32:02     INFO - GECKO(1500) | [Parent 1500: Main Thread]: I/DocShellAndDOMWindowLeak --DOMWINDOW == 46 (7f5be3094c00) [pid = 1500] [serial = 928] [outer = 0] [url = about:blank]
[task 2026-02-23T22:32:02.366+00:00] 22:32:02     INFO - GECKO(1500) | [Parent 1500: Main Thread]: I/DocShellAndDOMWindowLeak --DOCSHELL 7f5c18d04800 == 14 [pid = 1500] [id = 387] [url = chrome://browser/content/browser.xhtml]
[task 2026-02-23T22:32:02.366+00:00] 22:32:02     INFO - GECKO(1500) | [Parent 1500: Main Thread]: I/DocShellAndDOMWindowLeak --DOCSHELL 7f5c2a0af000 == 13 [pid = 1500] [id = 397] [url = chrome://browser/content/browser.xhtml]
[task 2026-02-23T22:32:02.367+00:00] 22:32:02     INFO - GECKO(1500) | [Parent 1500: Main Thread]: I/DocShellAndDOMWindowLeak --DOCSHELL 7f5c4b906c00 == 12 [pid = 1500] [id = 395] [url = chrome://browser/content/browser.xhtml]
[task 2026-02-23T22:32:02.368+00:00] 22:32:02     INFO - GECKO(1500) | [Parent 1500: Main Thread]: I/DocShellAndDOMWindowLeak --DOCSHELL 7f5c1c0c5800 == 11 [pid = 1500] [id = 391] [url = chrome://browser/content/browser.xhtml]
[task 2026-02-23T22:32:02.369+00:00] 22:32:02     INFO - GECKO(1500) | [Parent 1500: Main Thread]: I/DocShellAndDOMWindowLeak --DOCSHELL 7f5c2a0adc00 == 10 [pid = 1500] [id = 393] [url = chrome://browser/content/browser.xhtml]
[task 2026-02-23T22:32:02.369+00:00] 22:32:02     INFO - GECKO(1500) | [Parent 1500: Main Thread]: I/DocShellAndDOMWindowLeak --DOCSHELL 7f5bfd3b5c00 == 9 [pid = 1500] [id = 389] [url = chrome://browser/content/browser.xhtml]
[task 2026-02-23T22:32:02.370+00:00] 22:32:02     INFO - GECKO(1500) | [Parent 1500: Main Thread]: I/DocShellAndDOMWindowLeak --DOCSHELL 7f5c2a432800 == 8 [pid = 1500] [id = 402] [url = about:blank]
[task 2026-02-23T22:32:02.371+00:00] 22:32:02     INFO - GECKO(1500) | ### XPCOM_MEM_BLOAT_LOG defined -- logging bloat/leaks to /tmp/tmppt9k87je.mozrunner/runtests_leaks_tab_pid15092.lo
<...>
INFO - GECKO(1500) | [Parent 1500, sqldb:places.sqlite #4] WARNING: Suboptimal indexes for the SQL statement 0x7f5c29273480 (http://mzl.la/1FuID0j).: file /builds/worker/checkouts/gecko/storage/mozStoragePrivateHelpers.cpp:114
[task 2026-02-23T22:32:07.136+00:00] 22:32:07     INFO - GECKO(1500) | [Child 15173: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 3 (7f0dcdd4b000) [pid = 15173] [serial = 3] [outer = 7f0dd256f800]
[task 2026-02-23T22:32:07.176+00:00] 22:32:07     INFO - GECKO(1500) | [Parent 1500: Main Thread]: I/DocShellAndDOMWindowLeak ++DOCSHELL 7f5c2a435000 == 15 [pid = 1500] [id = 411]
[task 2026-02-23T22:32:07.176+00:00] 22:32:07     INFO - GECKO(1500) | [Parent 1500: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 59 (7f5c2cc8ec00) [pid = 1500] [serial = 981] [outer = 0]
[task 2026-02-23T22:32:07.177+00:00] 22:32:07     INFO - GECKO(1500) | [Parent 1500: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 60 (7f5c1da40400) [pid = 1500] [serial = 982] [outer = 7f5c2cc8ec00]
[task 2026-02-23T22:32:07.249+00:00] 22:32:07     INFO - GECKO(1500) | [Parent 1500, Main Thread] WARNING: NS_ENSURE_SUCCESS_VOID(rv) failed with result 0x804B000A (NS_ERROR_MALFORMED_URI): file /builds/worker/checkouts/gecko/dom/base/Document.cpp:17565
[task 2026-02-23T22:32:07.250+00:00] 22:32:07     INFO - GECKO(1500) | [Parent 1500: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 61 (7f5c1279dc00) [pid = 1500] [serial = 983] [outer = 7f5c2cc8ec00]
[task 2026-02-23T22:32:07.262+00:00] 22:32:07     INFO - GECKO(1500) | [Parent 1500, Main Thread] WARNING: Failed to retarget HTML data delivery to the parser thread.: file /builds/worker/checkouts/gecko/parser/html/nsHtml5StreamParser.cpp:1227
[task 2026-02-23T22:32:07.445+00:00] 22:32:07     INFO - GECKO(1500) | [1500] Assertion failure: moduleScript == existingEntry.Data(), at /builds/worker/checkouts/gecko/js/loader/ModuleLoaderBase.cpp:1711
[task 2026-02-23T22:32:07.446+00:00] 22:32:07     INFO - GECKO(1500) | #01: JS::loader::ModuleLoaderBase::MoveModulesTo(JS::loader::ModuleLoaderBase*) [git:github.com/mozilla-firefox/firefox:js/loader/ModuleLoaderBase.cpp:25aec1efe5a3c90bfeaaee6f37944d340b877aeb:1711]
[task 2026-02-23T22:32:07.447+00:00] 22:32:07     INFO - GECKO(1500) | #02: mozilla::dom::ChromeUtils::ImportESModule(mozilla::dom::GlobalObject const&, nsTSubstring<char16_t> const&, mozilla::dom::ImportESModuleOptionsDictionary const&, JS::MutableHandle<JSObject*>, mozilla::ErrorResult&) [git:github.com/mozilla-firefox/firefox:dom/base/ChromeUtils.cpp:25aec1efe5a3c90bfeaaee6f37944d340b877aeb:0]
[task 2026-02-23T22:32:07.448+00:00] 22:32:07     INFO - GECKO(1500) | #03: mozilla::dom::ChromeUtils_Binding::importESModule(JSContext*, unsigned int, JS::Value*) [s3:gecko-generated-sources:86a20671bb3f1dc1574a18bb94bfd7a29feead87435899806fd875e56c706ebc6e6679ec48df5a82810a04c30c836196d63d873821d676d9168206824adade18/dom/bindings/ChromeUtilsBinding.cpp::4758]
[task 2026-02-23T22:32:07.449+00:00] 22:32:07     INFO - GECKO(1500) | #04: CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) [git:github.com/mozilla-firefox/firefox:js/src/vm/Interpreter.cpp:25aec1efe5a3c90bfeaaee6f37944d340b877aeb:490]
[task 2026-02-23T22:32:07.450+00:00] 22:32:07     INFO - GECKO(1500) | #05: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) [git:github.com/mozilla-firefox/firefox:js/src/vm/Interpreter.cpp:25aec1efe5a3c90bfeaaee6f37944d340b877aeb:586]
[task 2026-02-23T22:32:07.450+00:00] 22:32:07     INFO - GECKO(1500) | #06: js::Interpret(JSContext*, js::RunState&) [git:github.com/mozilla-firefox/firefox:js/src/vm/Interpreter.cpp:25aec1efe5a3c90bfeaaee6f37944d340b877aeb:0]
[task 2026-02-23T22:32:07.451+00:00] 22:32:07     INFO - GECKO(1500) | #07: js::RunScript(JSContext*, js::RunState&) [git:github.com/mozilla-firefox/firefox:js/src/vm/Interpreter.cpp:25aec1efe5a3c90bfeaaee6f37944d340b877aeb:0]
[task 2026-02-23T22:32:07.452+00:00] 22:32:07     INFO - GECKO(1500) | #08: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) [git:github.com/mozilla-firefox/firefox:js/src/vm/Interpreter.cpp:25aec1efe5a3c90bfeaaee6f37944d340b877aeb:618]
[task 2026-02-23T22:32:07.452+00:00] 22:32:07     INFO - GECKO(1500) | #09: js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) [git:github.com/mozilla-firefox/firefox:js/src/vm/Interpreter.cpp:25aec1efe5a3c90bfeaaee6f37944d340b877aeb:685]
[task 2026-02-23T22:32:07.453+00:00] 22:32:07     INFO - GECKO(1500) | #10: JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) [git:github.com/mozilla-firefox/firefox:js/src/vm/CallAndConstruct.cpp:25aec1efe5a3c90bfeaaee6f37944d340b877aeb:119]
[task 2026-02-23T22:32:07.454+00:00] 22:32:07     INFO - GECKO(1500) | #11: mozilla::dom::CustomElementCreationCallback::Call(mozilla::dom::BindingCallContext&, JS::Handle<JS::Value>, nsTSubstring<char16_t> const&, mozilla::ErrorResult&) [s3:gecko-generated-sources:ea9f912ebaa18bac26927160302c47e63fc7c1eba4082b2b041f875cec0952d19119ee3009279c85d20e4e52b9b7527802e274f18999afefdd1ee5f471251375/dom/bindings/ConsoleInstanceBinding.cpp::298]
[task 2026-02-23T22:32:07.455+00:00] 22:32:07     INFO - GECKO(1500) | #12: mozilla::dom::CustomElementCreationCallback::Call(nsTSubstring<char16_t> const&, mozilla::ErrorResult&, char const*, mozilla::dom::CallbackObjectBase::ExceptionHandling, JS::Realm*) [s3:gecko-generated-sources:3da00321c6962b4f7bd42da9e79763561141d667de174259f9ba5780220ab5bc5c05216e0af61607fdac5dcf63efb565b28a8f18fb0c922a2d8e218681e914a8/dist/include/mozilla/dom/CustomElementRegistryBinding.h::0]
[task 2026-02-23T22:32:07.455+00:00] 22:32:07     INFO - GECKO(1500) | #13: mozilla::dom::CustomElementRegistry::RunCustomElementCreationCallback::Run() [git:github.com/mozilla-firefox/firefox:dom/base/CustomElementRegistry.cpp:25aec1efe5a3c90bfeaaee6f37944d340b877aeb:531]
[task 2026-02-23T22:32:07.456+00:00] 22:32:07     INFO - GECKO(1500) | #14: nsContentUtils::RemoveScriptBlocker() [git:github.com/mozilla-firefox/firefox:dom/base/nsContentUtils.cpp:25aec1efe5a3c90bfeaaee6f37944d340b877aeb:7119]
[task 2026-02-23T22:32:07.457+00:00] 22:32:07     INFO - GECKO(1500) | #15: nsINode::CloneAndAdopt(nsINode*, bool, bool, nsNodeInfoManager*, JS::Handle<JSObject*>, nsINode*, mozilla::ErrorResult&) [git:github.com/mozilla-firefox/firefox:dom/base/nsINode.cpp:25aec1efe5a3c90bfeaaee6f37944d340b877aeb:4068]
[task 2026-02-23T22:32:07.457+00:00] 22:32:07     INFO - GECKO(1500) | #16: nsINode::Clone(bool, nsNodeInfoManager*, mozilla::ErrorResult&) [git:github.com/mozilla-firefox/firefox:dom/base/nsINode.cpp:25aec1efe5a3c90bfeaaee6f37944d340b877aeb:4105]
[task 2026-02-23T22:32:07.458+00:00] 22:32:07     INFO - GECKO(1500) | #17: mozilla::dom::Document::ImportNode(nsINode&, bool, mozilla::ErrorResult&) const [git:github.com/mozilla-firefox/firefox:dom/base/Document.cpp:25aec1efe5a3c90bfeaaee6f37944d340b877aeb:9401]
[task 2026-02-23T22:32:07.459+00:00] 22:32:07     INFO - GECKO(1500) | #18: mozilla::dom::Document_Binding::importNode(JSContext*, JS::Handle<JSObject*>, void*, JSJitMethodCallArgs const&) [s3:gecko-generated-sources:b469cc5bcacb41c5a76f33d1fed52a5fd85e620bd81a8fe6394086e7c95b11e44f60b2e94574d07e1a386d7e4ffe9b59a77224ac067ecc3f40678956c1cc23cd/dom/bindings/DocumentBinding.cpp::2743]
[task 2026-02-23T22:32:07.459+00:00] 22:32:07     INFO - GECKO(1500) | #19: mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>(JSContext*, unsigned int, JS::Value*) [git:github.com/mozilla-firefox/firefox:dom/bindings/BindingUtils.cpp:25aec1efe5a3c90bfeaaee6f37944d340b877aeb:3306]
[task 2026-02-23T22:32:07.460+00:00] 22:32:07     INFO - GECKO(1500) | #20: ??? (???:???)
[task 2026-02-23T22:32:07.460+00:00] 22:32:07     INFO - GECKO(1500) | ExceptionHandler::GenerateDump attempting to generate:/tmp/tmppt9k87je.mozrunner/minidumps/61279af3-b5a4-60c2-4587-c817093e3678.dmp
[task 2026-02-23T22:32:07.473+00:00] 22:32:07     INFO - GECKO(1500) | ExceptionHandler::WaitForContinueSignal waiting for continue signal...
[task 2026-02-23T22:32:07.474+00:00] 22:32:07     INFO - GECKO(1500) | ExceptionHandler::GenerateDump cloned child 15308
[task 2026-02-23T22:32:07.474+00:00] 22:32:07     INFO - GECKO(1500) | ExceptionHandler::SendContinueSignalToChild sent continue signal to child
[task 2026-02-23T22:32:07.793+00:00] 22:32:07     INFO - GECKO(1500) | ExceptionHandler::GenerateDump minidump generation succeeded

Comment 1

[Intermittent Failures Robot]

37 failures were associated with this bug yesterday.

Repository breakdown:

• autoland: 34
• mozilla-central: 2
• try: 1

Table

	msix	no_variant	swr
linux2404-x86_64/debug			18
macosx1015-x86_64/debug		2
windows11-x86/debug		7
windows11-x86_64/debug	6	4

For more details, see:

https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=2018794&startday=2026-02-24&endday=2026-02-24&tree=all

Comment 2

[Tooru Fujisawa [:arai]]

The assertion failure happens because chrome://global/content/elements/moz-label.mjs is imported both by a normal module loader (<script type="module">, dynamic import() etc) and the sync module loader (ChromeUtils.importESModule).

Single module should be imported only by either of them, otherwise it results in a race between those module loaders, and it leads to an inconsistent behavior depending on which one imports first.
The assertion ensures the situation never happens.

Some more context in bug 1803810, which implemented the sync module loader.

The assertion failure happens in the following scenario:

1. A normal module loader imports chrome://global/content/elements/moz-label.mjs
2. the import for moz-label.mjs fails with "Loading failed for the module with source" error message, and creates an error entry
3. The sync module loader imports chrome://global/content/elements/moz-label.mjs
4. the import for moz-label.mjs succeeds, and the sync module loader tries to move the loaded module to the normal module loader
5. given the normal module loader already has an error entry for moz-label.mjs, the move fails with the assertion failure

https://searchfox.org/firefox-main/rev/1f43fe5ffadde0b6898daf607cabb3335dd75d6f/dom/locales/en-US/chrome/dom/dom.properties#336

ModuleSourceLoadFailed=Loading failed for the module with source “%S”.

https://searchfox.org/firefox-main/rev/1f43fe5ffadde0b6898daf607cabb3335dd75d6f/dom/script/ScriptLoader.cpp#4450

message = isScript ? "ScriptSourceLoadFailed" : "ModuleSourceLoadFailed";

https://searchfox.org/firefox-main/rev/1f43fe5ffadde0b6898daf607cabb3335dd75d6f/js/loader/ModuleLoaderBase.cpp#684

mFetchedModules.InsertOrUpdate(moduleMapKey, RefPtr{moduleScript});

https://searchfox.org/firefox-main/rev/1f43fe5ffadde0b6898daf607cabb3335dd75d6f/js/loader/ModuleLoaderBase.cpp#1699,1703,1715

void ModuleLoaderBase::MoveModulesTo(ModuleLoaderBase* aDest) {
...
  for (const auto& entry : mFetchedModules) {
...
    aDest->mFetchedModules.InsertOrUpdate(entry, moduleScript);

A tentative solution is to copy the error entry also to the sync module loader, which at least avoids the assertion failure:

https://searchfox.org/firefox-main/rev/1f43fe5ffadde0b6898daf607cabb3335dd75d6f/js/loader/ModuleLoaderBase.cpp#1685,1690-1696

void ModuleLoaderBase::CopyModulesTo(ModuleLoaderBase* aDest) {
...
  for (const auto& entry : mFetchedModules) {
    RefPtr<ModuleScript> moduleScript = entry.GetData();
    if (!moduleScript) {
      continue;
    }
    aDest->mFetchedModules.InsertOrUpdate(entry, moduleScript);
  }

But ultimately, either of the consumers of moz-label.mjs should stop using the current loader.

So far what I can see is the following:

• (a) The customElements imports moz-button.mjs using the sync module loader
  • moz-button.mjs imports moz-label.mjs, this also uses the sync module loader
• (b) Something imports moz-toggle.mjs using the normal module loader
  • moz-toggle.mjs imports moz-label.mjs, this also uses the normal module loader

There are some other code paths for both of the above, but anyway, this situation is not expected for the sync module loader.

(a) https://searchfox.org/firefox-main/rev/1f43fe5ffadde0b6898daf607cabb3335dd75d6f/toolkit/content/customElements.js#809,819,890-893,897,902,906-907

let acornElements = [
...
  ["moz-button", "chrome://global/content/elements/moz-button.mjs"],
...
];
document.addEventListener(
  "DOMContentLoaded",
  () => {
...
    for (let [tag, script] of acornElements) {
...
            ChromeUtils.importESModule(script, { global: "current" });
...
    }
  },

https://searchfox.org/firefox-main/rev/1f43fe5ffadde0b6898daf607cabb3335dd75d6f/toolkit/content/widgets/moz-button/moz-button.mjs#11

import "chrome://global/content/elements/moz-label.mjs";

(b) https://searchfox.org/firefox-main/search?q=rc%3D%22chrome%3A%2F%2Fglobal%2Fcontent%2Felements%2Fmoz-toggle.mjs%22&path=&case=false&regexp=false

https://searchfox.org/firefox-main/rev/1f43fe5ffadde0b6898daf607cabb3335dd75d6f/toolkit/content/widgets/moz-toggle/moz-toggle.mjs#8

import "chrome://global/content/elements/moz-label.mjs";

Comment 3

[Tooru Fujisawa [:arai]]

:hjones, can I have your input here?

Apparently the situation around the reusable component went unexpected way, where it breaks the invariant for the module loaders.

What's the expected usage of those modules? Why there are two types of consumers for those modules?

• <script type="module">
• ChromeUtils.importESModule(..., {global: "current"})

Comment 4

[Tooru Fujisawa [:arai]]

Attachment: An incomplete dependency graph for moz-label.mjs

I was checking the dependency graph of the moz-label.mjs, and apparently this problem spans across multiple components and the problem happens really widely.
So I guess sorting all of them out is not a realistic solution in short term.
I've filed bug 2019262 to at least avoid the assertion failure.

Comment 5

[Kelly Cochrane [:kcochrane]]

:arai I'm going to assign this to you since it seems you have some more context if that works?

Comment 6

[Intermittent Failures Robot]

37 failures were associated with this bug yesterday.

Repository breakdown:

• try: 3
• autoland: 28
• mozilla-central: 6

Table

	msix	no_variant	swr
linux2404-x86_64/debug			11
macosx1015-x86_64/debug		3
windows11-x86/debug		5
windows11-x86_64/debug	7	11

For more details, see:

https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=2018794&startday=2026-02-25&endday=2026-02-25&tree=all

Comment 7

[Tooru Fujisawa [:arai]]

Sure, I can look into the issue around the module loader part, but I need some more information from people who's developing and using the reusable component code, given the issue is mostly happening around that.
(the above dependency graph shows some more consumers that breaks the invariant tho...)

Setting the needinfo again, assuming it was redirected accidentally.
:hjones, can I get your input regarding comment #3 ?

If it's really necessary to import a single module both with the regular module loader and sync module loader,
we should re-design the sync module loader feature, given it's not really safe usage right now.

Comment 8

[Intermittent Failures Robot]

49 failures were associated with this bug yesterday.

Repository breakdown:

• try: 5
• autoland: 44

Table

	msix	no_variant	swr
linux2404-x86_64/debug			12
macosx1015-x86_64/debug		6
windows11-x86/debug		10
windows11-x86_64/debug	11	10

For more details, see:

https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=2018794&startday=2026-02-26&endday=2026-02-26&tree=all

Comment 9

[Tooru Fujisawa [:arai]]

There are five problems so far:

• (A) We're importing single module both with the regular module loader and the sync module loader
• (B) The testcase somehow aborts a module import, performed with the regular module loader, and that leaves an error entry in the global's module map
• (C) ChromeUtils.importESModule doesn't expect such module getting imported again (the first crash)
• (D) even if we support such case in ChromeUtils.importESModule, CustomElementRegistry::RunCustomElementCreationCallback::Run doesn't expect the callback to fail (the second crash after fixing C)
• (E) even if we somehow suppress the error in the custom element callback, the testcase seems to be discarding a document and global too quickly, during the initialization with custom elements and lit, and lit try to read a global variable that no longer exists, and thus it throws an error and the test fails

So, the one of the problem that needs to be addressed here is that the testcase discarding document and global too quickly.
I haven't yet spotted where it happens tho.

Comment 10

[Tooru Fujisawa [:arai]]

The problem (B) seems to be happening while opening about:opentabs in the following line,
and if I open the URL, it shows some UI for a few frames and then the page becomes empty.

https://searchfox.org/firefox-main/rev/4bc9c2f9b62e7cb44894d581c8171edbf0f7e27f/browser/components/urlbar/tests/browser/browser_switchTab_override.js#146-149

let tab2 = await BrowserTestUtils.openNewForegroundTab(
  gBrowser,
  "about:opentabs"
);

What does about:opentabs do when it's opened?
Does it perform navigation quickly?
Does it use custom elements and lit?

Comment 11

[Tooru Fujisawa [:arai]]

Looks like https://searchfox.org/firefox-main/source/browser/components/tabbrowser/content/opentabs.html is the page that's shown for about:opentabs.
it seems to be navigating while rendering, this would indeed cause trouble around custom elements, module imports, and lit.

https://searchfox.org/firefox-main/rev/4bc9c2f9b62e7cb44894d581c8171edbf0f7e27f/browser/components/tabbrowser/content/opentabs-splitview.mjs#146,160

render() {
...
    this.getWindow().openTrustedLinkIn(BROWSER_NEW_TAB_URL, "current");

Is the above correct?

if so, I guess it should wait for the next event tick or microtask checkpoint or something before navigating, or at least perform the navigation somewhere else.
I'll test a patch that moves it to next microtask.

Comment 12

[Kelly Cochrane [:kcochrane]]

(In reply to Tooru Fujisawa [:arai] from comment #10)

The problem (B) seems to be happening while opening about:opentabs in the following line,
and if I open the URL, it shows some UI for a few frames and then the page becomes empty.

https://searchfox.org/firefox-main/rev/4bc9c2f9b62e7cb44894d581c8171edbf0f7e27f/browser/components/urlbar/tests/browser/browser_switchTab_override.js#146-149

let tab2 = await BrowserTestUtils.openNewForegroundTab(
  gBrowser,
  "about:opentabs"
);

What does about:opentabs do when it's opened?
Does it perform navigation quickly?
Does it use custom elements and lit?

Hi! So the about:opentabs is supposed to be used when adding a new split view. With browser.tabs.splitView.enabled set to true and at least 2 unpinned tabs open, right click one of the tabs and select "Add Split View" in the context menu. This should display the page as expected. If the user doesn't have any other available tabs to be pulled into the split view or if a user tries to access about:opentabs outside of this context, we redirect to the new tab page.

Comment 13

[Tooru Fujisawa [:arai]]

thank you. that explains what's happening.
the testcase opens about:opentabs in the situation where it would redirect to the about:newtab, and during the redirect, the document and the global gets discarded, while the page is still initializing and rendering, and custom elements are getting constructed.
so, delaying the redirect should solve the crash here.

but the underlying bigger problems remains, and we should address them in other bugs.

Comment 14

[Tooru Fujisawa [:arai]]

Attachment: Bug 2018794 - Do not perform navigation during the custom element and lit handling in about:opentabs. r?kcochrane!

Comment 15

[Intermittent Failures Robot]

65 failures were associated with this bug yesterday.

Repository breakdown:

• autoland: 56
• mozilla-central: 7
• try: 2

Table

	msix	no_variant	swr
linux2404-x86_64/debug			21
macosx1015-x86_64/debug		7
windows11-x86/debug		12
windows11-x86_64/debug	11	14

For more details, see:

https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=2018794&startday=2026-02-27&endday=2026-02-27&tree=all

Comment 16

[Intermittent Failures Robot]

20 failures were associated with this bug yesterday.

Repository breakdown:

• autoland: 18
• mozilla-central: 2

Table

	msix	no_variant	swr
linux2404-x86_64/debug			8
macosx1015-x86_64/debug		2
windows11-x86/debug		3
windows11-x86_64/debug	6	1

For more details, see:

https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=2018794&startday=2026-02-28&endday=2026-02-28&tree=all

Comment 17

[Intermittent Failures Robot]

220 failures were associated with this bug in the last 7 days.
This is the #9 most frequent failure this week.

This failure happened more than 75 times this week! Resolving this bug is a very high priority.

Try to resolve this bug as soon as possible. If unresolved for 1 week, the affected test(s) may be disabled.

Repository breakdown:

• autoland: 190
• mozilla-central: 18
• try: 12

Table

	msix	no_variant	swr
linux2404-x86_64/debug			79
macosx1015-x86_64/debug		20
windows11-x86/debug		38
windows11-x86_64/debug	42	41

For more details, see:

https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=2018794&startday=2026-02-23&endday=2026-03-01&tree=all

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/07c36c91a83c
https://hg.mozilla.org/integration/autoland/rev/348bda46851b
Do not perform navigation during the custom element and lit handling in about:opentabs. r=kcochrane,tabbrowser-reviewers

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 2010624

Comment 20

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/348bda46851b

Comment 21

[Intermittent Failures Robot]

15 failures were associated with this bug yesterday.

Repository breakdown:

• autoland: 13
• mozilla-central: 2

Table

	msix	no_variant	swr
linux2404-x86_64/debug			4
macosx1015-x86_64/debug		4
windows11-x86/debug		1
windows11-x86_64/debug	1	5

For more details, see:

https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=2018794&startday=2026-03-02&endday=2026-03-02&tree=all

Comment 22

[Hanna Jones [:hjones]]

(In reply to Tooru Fujisawa [:arai] from comment #3)

:hjones, can I have your input here?

Apparently the situation around the reusable component went unexpected way, where it breaks the invariant for the module loaders.

What's the expected usage of those modules? Why there are two types of consumers for those modules?

• <script type="module">
• ChromeUtils.importESModule(..., {global: "current"})

Hi :arai - sorry for the slow reply, I missed the original needinfo. I think our preference for developer experience/ease of use would be to stick with the sync loader-backed auto loading of the custom element code via tag name - provided there are no performance or other concerns associated with that solution. I think we've ended up with two types of consumers for those modules for a couple reasons:

• code that was written before the work in bug 1803810 and bug 1803678 and therefore had to use <script type="module"> and never got refactored
• lack of developer awareness of the code that auto imports the elements in customElements.js

To compliment what you're working on in bug 2020605 we could feasibly implement a custom ESLint rule to warn developers against using <script type="module"> for any elements in this array + undertake removing any unnecessary <script type="module"> tags. Does that sound like a reasonable path forward to you?

Comment 23

[Tooru Fujisawa [:arai]]

thank you for your answer!

Yes, if we can enforce the use of either of the module loader by ESLint, that will definitely help.
Sync loader doesn't have any notable concern around the performance, so moving to the sync loader for all cases should be totally fine.

For the ESLint, the problem would be that the modules shouldn't overlap even in the dependencies.
for example, lit.all.mjs is imported by those modules, and that module shouldn't also be imported in the dependency of <script type="module">,
So, maybe a static analysis might not be sufficient (or too complex, to compare the module dependency graph), and we may need to add debug-only code to track all modules imported with sync module loader.

I'll look into the runtime enforcement in bug 2020605. let me know if there's anything need to be done on runtime.

Comment 24

[Tooru Fujisawa [:arai]]

actually, some modules are used both in privileged global and the unprivileged global.
for example moz-button.mjs is imported in about:newtab, which is unprivileged, and has no access to ChromeUtils.
And thus importing it with regular import declaration is valid there.
So, if we're to apply ESLint rule, it should be selectively applied based on in which global the module is imported into.

Comment 25

[Intermittent Failures Robot]

17 failures were associated with this bug in the last 7 days.

Repository breakdown:

• autoland: 13
• mozilla-central: 2
• try: 2

Table

	msix	no_variant	swr
linux2404-x86_64/debug			4
macosx1015-x86_64/debug		4
windows11-x86/debug		1
windows11-x86_64/debug	2	6

For more details, see:

https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=2018794&startday=2026-03-02&endday=2026-03-08&tree=all