Closed Bug 1026254 Opened 7 years ago Closed 7 years ago
No error page when trying to load a chrome: URL using an unregistered package
If you try to load a chrome: URL for a missing file in a registered package, you get the "Problem loading page" display. But if you try to load a chrome: URL for a missing package, nothing happens. This is because the chrome protocol returns NS_ERROR_UNEXPECTED in this case. We can make it return NS_ERROR_FILE_NOT_FOUND instead which will allow the doc shell to display an error page. There are a few bugs reporting hidden blank chrome documents showing up in the Window menu; if these are actually caused by invalid chrome: URLs then the error page would give us more information. (It should then be possible to scrape the error page using DOM Inspector for example.)
> NS_ERROR_UNEXPECTED Actually NS_ERROR_FAILURE or NS_ERROR_NOT_AVAILABLE, depending.
Assignee: nobody → neil
Status: NEW → ASSIGNED
Attachment #8441035 - Flags: review?(benjamin)
Try tells me that we have a test for the error code, so I'll need to patch that too.
Attachment #8441035 - Attachment description: 1026254.diff → Proposed patch
This landed with the wrong bug number - and the bug number it uses is a private bug, so I can't comment there to point this way. I don't suppose you could backout and reland (in one push, as two commits, and with DONTBUILD in the topmost commit), so hg blame points here? :-) https://hg.mozilla.org/mozilla-central/rev/0b04aefdd3e3
This was backed out as changeset b85caf0e485a because the patch for bug 1026008 caused leaks. Re-landed as https://hg.mozilla.org/integration/mozilla-inbound/rev/c843ae1b1eb2
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 7 years ago → 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.