1880166 - commonDialog.xhtml ends up in startupCache or XUL fastload (or something?) "wrong", breaking future dialogs, likely triggered by unloading a dialog before it finished loading

Status: RESOLVED DUPLICATE of bug 1880262

(Core :: XPCOM, defect)

Description

[:Gijs (he/him)]

Attachment: Screenshot of dialog content producing a parsing error (which isn't fully visible)

I appear to have hit a race condition when testing some recent fixes I made to the dialog code.

I started with a build from 2024-02-11, and tried the testcase on bug 1873068. That hung the browser (as per comment 0 there). I force quit it.

This testcase tries to open an alert() (which loads commonDialog.xhtml in a XUL <browser> inside browser.xhtml), and for complex reasons outlined in that bug will close (abort) it immediately, without even waiting for that dialog to load, and will then go into some kind of loop.

Then updated to today's nightly (2024-02-13) and tried both that testcase and the one in bug 1833875. These testcases would still be opening and immediately closing those dialogs, but no longer go into the loop so I didn't need to force quit.

Some point later I tried to quit the browser with the cmd-Q shortcut - and no "are you sure you want to quit" dialog showed up, but the browser background did go grey. I opened the browser console, and that showed some issues:

XML Parsing Error: no element found
Location: chrome://global/content/commonDialog.xhtml
Line Number 1, Column 1:

This looks effectively like a yellow screen of death, only it wasn't visible because the SubDialog code waits for the load event to be emitted from its framed document before removing visibility styling hiding the content, cf. https://searchfox.org/mozilla-central/rev/4fe00e0322377316390da6faa2d645cae53d08f4/toolkit/modules/SubDialog.sys.mjs#541 (called from onLoad).

This then reproduced every time I continued to try to quit the browser.

The hypothesis, which :jesup, :emilio, :smaug and I all thought likely (but can't 100% confirm because I hit this in a "normal" distributed nightly build which I can't easily debug, and I so far haven't been able to reproduce the same thing despite repeated tries) is that we've ended up dumping an incomplete/missing set of content into either startup or XUL fastload cache, and now keep regurgitating this.

It seems potentially possible that the issue encountered in bug 1639821 is the same in some way: if there are situations where we try to load the webrtc dialog but abort doing so before we finish loading the content, and that result gets cached somehow, it would explain why subsequent attempts to open it would continue to break.

Comment 1

[:Gijs (he/him)]

Going to dupe this to the issue where Olli is addressing this problem.