1799973 - Going to XUL test-case shows unresponsive page rather than error

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[Emilio Cobos Álvarez (:emilio)]

STR: Click on this link: attachment 417962 [details]

ER: Error page probably? Or at least I can click and scroll on the page I see once the tab spinner stops?

AR: Page freezes, no history entry or anything.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Filing because I believe this is probably not exclusive to XUL content-type or what not.

Comment 2

[Daniel Holbert [:dholbert]]

I see a variety of error pages when bisecting between 2018 and current builds.

2019-06-01 gives me an error page about remote XUL.
2019-12-01 gives me a yellow XML syntax error page.
2020-2021ish builds give me no error page; the navigation just stops, I'm still looking at this same Bugzilla page, and I can interact with it (e.g. I can click "Details" in comment 0)
2022ish builds give me the page freeze (can't click anything, e.g. can't click "Details" link in comment 0 here).

The regression range for switching to the page-freeze behavior is when we enabled fission:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=383986e2f5cb835a55c47bbd6e15d81035ca0784&tochange=d6e8528f0a936df88369c71f4e390e31a4d621a1

Comment 3

[Daniel Holbert [:dholbert]]

With fission manually enabled, we can go back a bit further. There are a few behavior-changes that are worth noting:

CHANGE #1:
2019-12-23: yellow XML syntax error page (with functional back button). This seems like sort-of EXPECTED RESULTS.
2019-12-24: blank page, back button does nothing; download dialog appears for the XUL file. No history entry added (back button doesn't work, though I can long-press it and choose a dropdown entry if I have some further-back history). (The download dialog here is probably expected/desired, but the blank page and history nerfing seems unwanted and is part of the key issue here.)

Pushlog for that^ behavior-change:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=99d782b09b7d036db2596201c7dae8baf06de85e&tochange=48159e53bfb85d9b22e94ecaaa6590ab4abd9545

In there, I would bet this was "Bug 1601110, remove handling and references to vnd.mozilla.xul+xml"

CHANGE #2:
The next change is on 2020-06-27 where (starting with that Nightly) we don't show a file download dialog for the XUL file anymore. Aside from that lack of a dialog, the results seem to stay the same as discussed above for change #1 (still a blank page, no history entry added, back button doesn't work).

Pushlog for that behavior-change:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9b981fcfb6ac3119837605e3189c5832446c77ab&tochange=ca79c56a0a1b6fcbf823ee46973951b133a73a0c
(Not sure offhand what in there would've caused this change, but it might not matter much.)

CHANGE #3:
The next change is on 2021-08-02 where the page just looks like it freezes (the current behavior, as described in comment 0) and is no longer blank.
Pushlog for that behavior-change:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ea89827501c6f1abd7451f894221eebc367b2be0&tochange=3ff8ac39b364436a63b387f445899a7db0d3ddd8

In that pushlog, I would bet the relevant change was:
"Bug 1677324 - Keep painting the of the old remote frame when going into the bfcache until the child unsuppresses painting"

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: trivial pptx file (for comparison)

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: trivial vsd file (for comparison)

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: trivial XUL file (for comparison)

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: trivial "XAL" file (not a real thing), for comparison

Here's an attachment using the bogus content type "application/vnd.mozilla.xal+xml" (like XUL but with "a" instead of "u"), just to see how we handle entirely unrecognized content types.

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #1)

Filing because I believe this is probably not exclusive to XUL content-type or what not.

Yeah, so we know application/vnd.mozilla.xul+xml seems to be affected.

I attached a two other attachments with real-but-not-webby application/[stuff] content-types here and they're unaffected; and I attached one bogus made up one ("xal") and it's unaffected as well. All of these kick off a download, and the page doesn't navigate and stays responsive.

So at this point this does seem to be specific to the XUL content-type.

Comment 9

[Daniel Holbert [:dholbert]]

If I load the XUL attachment vs. the bogus XAL attachment and inspect our MOZ_LOG="URILoader:5" logging, it looks like the first difference is that XUL gets Success! Our default listener likes this type vs. XAL gets a NS_ENSURE_SUCCESS failure with NS_ERROR_FACTORY_NOT_REGISTERED in DocumentLoadListener.cpp.

So it seems we have a listener registered for XUL despite the aforementioned "Bug 1601110, remove handling and references to vnd.mozilla.xul+xml".
Looks like this one in particular:
https://searchfox.org/mozilla-central/rev/dd216c1307a2bf1b0d2465b9749fa86dac44303a/layout/build/components.conf#22

And indeed, if I remove that line, then the XUL file behaves just like the XAL file here and just triggers a file download.

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: Bug 1799973: Remove one straggling mention of the XUL content-type, 'application/vnd.mozilla.xul+xml'. r?emilio

We intended to remove all references to this content type in bug 1601110, but
it looks like this instance was overlooked.

This patch mostly doesn't affect users, but it does result in one small
behavior difference:

• Before this patch, if you click a link to a XUL file, you end up getting a
  partial failed load which seems to get dropped on the floor.
• After this patch, you'll instead get a file download, just as you would for
  any other unrecognized file type.

Comment 11

[Daniel Holbert [:dholbert]]

The attached patch seems to fix the error for me by removing the XUL content-type from layout/build/components.conf.

Moreover, I can introduce the same issue for my bogus "XAL" attachment if I instead add my bogus XAL content-type there (taking the place of our XUL content type listing).

So: I think that doubly-confirms that that's one root cause for this issue.

(Ideally we should probably separately figure out if it's possible to either make the error-handling fallback behavior a little more graceful, or fatally assert so that it'd trigger alarms in our fuzzers, so that we don't accidentally get into this situation again in the future.)

Comment 12

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

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

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/706788071c36
Remove one straggling mention of the XUL content-type, 'application/vnd.mozilla.xul+xml'. r=emilio

Comment 14

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/706788071c36

Comment 15

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

The patch landed in nightly and beta is affected.
:dholbert, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox107 to wontfix.

For more information, please visit auto_nag documentation.

Comment 16

[Daniel Holbert [:dholbert]]

Not important enough to uplift.