about:neterror/certerror fallback is broken (it breaks if the error code does not match an existing element)
Categories
(Firefox :: Security, defect, P2)
Tracking
()
People
(Reporter: Gijs, Unassigned)
References
(Blocks 2 open bugs, Regression, )
Details
(Keywords: regression, Whiteboard: [fxprivacy])
Attachments
(3 files)
screenshot of broken UI flicker, in comment 19's screencast
Comments in bug 1267514 pointed out that bug has re-occurred. I can confirm in 85 beta, just loading about:neterror manually loads a completely broken page. It's unclear exactly what broke this.
We should add an automated test to avoid regressing this again.
+++ This bug was initially created as a clone of Bug #1267514 +++
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20160425102203
Steps to reproduce:
- Start latest Nightly
- Go to about:neterror (or about:certerror)
Actual results:
Cannot display the problem loading page (Oops.) with correct layout.
Expected results:
Displays the problem loading page with correct layout.
|
||
Comment 1•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
|
Reporter | |
Comment 2•4 years ago
|
||
Merry Christmas to you too, relmanbot...
|
||
Comment 3•4 years ago
|
||
|
|
||
Comment 4•4 years ago
•
|
||
The layout isn't the real problem, actually. The problem is that the title text is missing entirely (and that's why the layout is broken).
You can see that in devtools -- <h1 class="title-text"> is empty (whereas in older builds, it contains the text "Oops"); and the web console has this uncaught error:
Uncaught ReferenceError: RPMGetInnerMostURI is not defined
<anonymous> chrome://browser/content/aboutNetError.js:14
RPMGetInnerMostURI is a function that was added in bug 941354.
Johann, mind taking a look after the holidays?
Thank you very much for your effort.
firefox-esr78 is not affected.
Happy holidays to you all.
Fore the new year I wish you all the best.
Stay safe.
cheers
Endor
|
|
Reporter | |
Updated•4 years ago
|
|
||
Comment 6•4 years ago
|
||
This seems like a pretty severe regression. Can we prioritize a fix for a possible dot release ride-along?
|
||
Comment 7•4 years ago
|
||
I can take a look, apparently the RPM actor script isn't injected into these for some reason, though I don't think there's any particular rush to fix this. There's no reason for any user to enter "about:certerror" manually in their url bar.
|
|
||
Comment 8•4 years ago
|
||
Thanks for the clarification.
|
|
||
Comment 9•4 years ago
|
||
Bug 1267514 comment 3 suggests there are cases when a user could hit this (when we don't have a more specific error message available), but I don't know how common that is.
|
|
Reporter | |
Comment 10•4 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #9)
Bug 1267514 comment 3 suggests there are cases when a user could hit this (when we don't have a more specific error message available), but I don't know how common that is.
I think this was the case in the original bug, but we don't have evidence right now that it is the case here. The specific error message (about the RPM script not being injected) seems likely to have to do with how the page is loaded and what principals are used, rather than not having a specific error message -- though I'm speculating, so I could definitely be wrong about this.
|
|
Reporter | |
Comment 11•4 years ago
|
||
In fact, it looks like about:neterror? works, but about:neterror doesn't, courtesy of the expression at https://searchfox.org/mozilla-central/rev/519f913527b0d9d5097d290d5731cff6b2991fe0/browser/components/BrowserGlue.jsm#544 .
There's a trivial way of fixing this (add about:neterror or about:certerror to the list of match expressions), but I don't know if that has perf implications. Using about:neterror* would not be ideal because it might start applying to other about pages if we prefix-match...
What I don't understand is why people even load these pages without query parameters. endor8 / boersenfeger: can you clarify why/how you end up loading these pages without any query parameters? I don't think gecko ever does this by itself.
|
|
Reporter | |
Comment 12•4 years ago
|
||
Bah, didn't mean to steal this in the end.
|
||
Comment 13•4 years ago
•
|
||
Hi, Gijs
we pimp all about: pages with CSS codes ;-))
In the process, the two pages caught our eye and we discovered the incorrect display.
The call is made by manual input via the URL bar.
/* AGENT_SHEET */
@-moz-document url-prefix(about:neterror),
url-prefix(about:certerror){
html{background:#ffffff !important;}
body,
body[class="illustrated connectionFailure neterror"],
body[class="illustrated netTimeout neterror"],
body[class="illustrated dnsNotFound neterror"],
body[class="illustrated malformedURI neterror"],
body[class="neterror"]{
justify-content: center!important;
margin-left: auto !important;
margin-right: auto !important;
max-width: 1200px !important;
min-height: 90vh !important;
max-height: 90vh !important;
margin-top: 30px !important;
margin-bottom: 20px !important;
padding-bottom: 20px !important;
padding-top: 15px !important;
padding-left: 50px !important;
padding-right: 50px !important;
background: #fffff0 !important;
border-left-color: lightblue!important;
border-top-color: lightblue!important;
border-right-color: dodgerblue!important;
border-bottom-color: dodgerblue!important;
border-radius: 20px !important;
border-width: 4px !important;
border-style: outset !important;}
#errorLongDesc{min-width: 580px !important;}
.title {
background-image: url("chrome://global/skin/icons/info.svg");
background-position: left 0;
background-repeat: no-repeat;
background-size: 1.6em;
margin-inline-start: -2.3em;
padding-inline-start: 2.3em;
font-size: 2.2em;
-moz-context-properties: fill;
fill: crimson !important;
height: auto !important;
min-height: 60px !important;}
html body.neterror div#errorPageContainer.container div#text-container div.title {
background-image: url("chrome://global/skin/icons/info.svg");
fill: #0060df !important;}
html body.neterror div#errorPageContainer.container div#text-container div.title h1.title-text{
color: #cc0000 !important;
font-size: 33px !important;
font-weight: bold !important;}
#errorLongDesc > strong:nth-child(1),
html body.neterror div#errorPageContainer.container div#text-container div#errorLongContent div#errorLongDesc p{
color: #1a75ff !important;
font-weight: bold !important;
font-size: 17px !important;}
button.try-again:nth-child(1){
min-width: 220px !important;
background: #0060df url("..//icons/reload.png") no-repeat !important;
padding-bottom: 10px !important;
padding-top: 9px !important;
padding-left: 40px !important;
background-position:16px 10px!important;
border-left-color: lightblue!important;
border-top-color: lightblue!important;
border-right-color: dodgerblue!important;
border-bottom-color: dodgerblue!important;
border-width:2px !important;
border-style: outset !important;
border-radius:22px!important;}
button.try-again:nth-child(1):hover{
background: #003eaa url("..//icons/reload.png") no-repeat !important;
background-position:16px 10px!important;
border-left-color: lightblue!important;
border-top-color: lightblue!important;
border-right-color: dodgerblue!important;
border-bottom-color: dodgerblue!important;
border-width:2px !important;
border-style: outset !important;
border-radius:22px!important;}
#learnMoreLink{
background: #efefef url("..//icons/Bild1.png") no-repeat !important;
color:black!important;
font-size:14px!important;
min-height: 25px!important;
margin-left: 14px!important;
text-decoration:none!important;
padding-right:15px!important;
padding-left:35px!important;
padding-bottom: 5px !important;
padding-top: 5px !important;
border-color: #A6A4A4 !important;
border-style: outset !important;
border-width:1px !important;
background-position:10px 7px!important;
border-radius:22px!important;
line-height: 2.5;}
#learnMoreLink:hover{
background: #E1F3FC url("..//icons/Bild1.png") no-repeat !important;
color:black!important;
font-size:14px!important;
text-decoration:none!important;
padding-right:15px!important;
padding-left:35px!important;
background-position:10px 7px!important;
border-style: outset !important;
border-width:1px !important;
border-radius:22px!important;}
#returnButton{
min-width: 220px !important;
background: #0060df url("..//icons/Undo.png") no-repeat !important;
padding-bottom: 10px !important;
padding-top: 9px !important;
padding-left: 40px !important;
background-position:16px 8px!important;
border-left-color: lightblue!important;
border-top-color: lightblue!important;
border-right-color: dodgerblue!important;
border-bottom-color: dodgerblue!important;
border-width:2px !important;
border-style: outset !important;
border-radius:22px!important;}
#returnButton:hover{
background: #003eaa url("..//icons/Undo.png") no-repeat !important;
background-position:16px 8px!important;
border-left-color: lightblue!important;
border-top-color: lightblue!important;
border-right-color: dodgerblue!important;
border-bottom-color: dodgerblue!important;
border-width:2px !important;
border-style: outset !important;
border-radius:22px!important;}
#advancedButton{
min-width: 220px !important;
background: #0060df url("..//icons/Bild79.png") no-repeat !important;
color: #ffffff !important;
padding-bottom: 10px !important;
padding-top: 9px !important;
padding-left: 40px !important;
background-position:18px 9px!important;
border-left-color: lightblue!important;
border-top-color: lightblue!important;
border-right-color: dodgerblue!important;
border-bottom-color: dodgerblue!important;
border-width:2px !important;
border-style: outset !important;
border-radius:22px!important;}
#advancedButton:hover{
background: #003eaa url("..//icons/Bild79.png") no-repeat !important;
background-position:18px 9px!important;
border-left-color: lightblue!important;
border-top-color: lightblue!important;
border-right-color: dodgerblue!important;
border-bottom-color: dodgerblue!important;
border-width:2px !important;
border-style: outset !important;
border-radius:22px!important;}
}
|
||
Comment 14•4 years ago
|
||
Hi Gijs.
Like Boersenfeger wrote, we pimp all about: pages with CSS codes ;-))
We are both members of the German Firefox Support Forum and there we pimp allot of Firefox.
I discovered the bug when I was checking the CSS code we created to see if everything was still
working after updating to Firefox 84.
I Hope it will fixed in a future Version of Firefox.
Thank you for your work.
Kind regards
Endor
|
||
Updated•4 years ago
|
|
|
||
Comment 15•4 years ago
•
|
||
(In reply to :Gijs (he/him) from comment #10)
(In reply to Daniel Holbert [:dholbert] from comment #9)
Bug 1267514 comment 3 suggests there are cases when a user could hit this
I think this was the case in the original bug, but we don't have evidence right now that it is the case here.
I just encountered this bug's broken rendering locally, for a brief moment of time, when loading an "Unable to connect" page (for http://localhost:8000/ when I had no web server running on that port).
I can reproduce this pretty reliably (for a visible moment during pageload) by putting my system under load (e.g. compiling Firefox in the background) and then visiting or reloading a tab that's showing http://localhost:8000 (or probably any network-error tab).
|
||
Updated•4 years ago
|
|
|
Reporter | |
Comment 16•4 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #15)
I can reproduce this pretty reliably (for a visible moment during pageload) by putting my system under load (e.g. compiling Firefox in the background) and then visiting or reloading a tab that's showing http://localhost:8000 (or probably any network-error tab).
I figured while I was building Firefox on Windows I could try this, but I cannot reproduce. Can you screencast what you mean? Are there any errors in the browser console when this happens?
|
|
||
Comment 17•4 years ago
|
||
|
|
||
Comment 18•4 years ago
•
|
||
(In reply to :Gijs (he/him) from comment #16)
I figured while I was building Firefox on Windows I could try this, but I cannot reproduce. Can you screencast what you mean?
Sure -- see attached. (Reproducibility note: I had to pause for a bit (maybe 0.5-1s) between each reload, in order to give the page a chance to re-render and exhibit the issue. If I simply mashed ctrl+r as fast as I can, then I don't see the issue, I suspect because we never finish reloading.)
Are there any errors in the browser console when this happens?
Yes, though these same errors happen on each reload of this localhost:8000 network-error page, regardless of whether I reproduce the bug; so I'm not sure they're related. But in any case, here's what shows up for each reload -- in the web console:
Cookie “CSRF-Token-TT2SM” has been treated as cross-site against “http://localhost:8000/” because the scheme does not match.
...and in the browser console:
Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. 2 background.js:2107
(That browser-console error is pointing to a call to chrome.runtime.sendMessage(message); in my Bitwarden Firefox extension, if it matters.)
|
|
||
Comment 19•4 years ago
•
|
||
I was also able to reproduce the issue in a local --enable-debug --enable-optimize=-O1 build (with a fresh profile, using the same error page viewing localhost:8000 with no web server listening there, while compiling another Firefox build in the background). No errors showed in the error console.
|
|
||
Comment 20•4 years ago
|
||
(In my local debug+opt build, the broken intermediate state would sometimes show up for around a full second, though I wasn't able to capture that in my screencast.)
|
|
||
Comment 21•4 years ago
|
||
(here's a screenshot from the video in comment 19, showing the moment when we flash the broken UI with the clipped image)
|
|
Reporter | |
Comment 22•4 years ago
|
||
devtools isn't indicating any sync flushes for me, and we run all the initialization code synchronously from the DOMContentLoaded event handler.
How realistic is the flash of unstyled content (which is more or less what this is) given those circumstances? Like, I don't really understand why layout and painting happens here, before the document has finished loading.
We might be able to fix it by moving the script load to the end of the DOM and then calling initPage sync when the document loads, but even there I'm not sure if that's possible given it's an XML doc. Moving away from it being an XML doc is a bunch more work.
|
|
||
Comment 23•4 years ago
|
||
(In reply to :Gijs (he/him) from comment #22)
How realistic is the flash of unstyled content (which is more or less what this is) given those circumstances? Like, I don't really understand why layout and painting happens here, before the document has finished loading.
It's entirely possible for layout and painting to happen during pageload (i.e. before the load event fires). The parser yields at various points which gives us an opportunity to layout & paint. We do suppress painting for a limited time (5ms I think?) to avoid flashes of unstyled content, but beyond that, I don't recall what controls whether or not we'll allow ourselves to layout/paint (and I think in general we'll let ourselves paint).
If you really want to be sure that nothing paints before some event fires, you might have to use display:none hacks to hide stuff until you're sure it's ready (and then be extra-super-sure that the event is going to fire). Maybe that's a terrible idea, though; I'm not sure. I think folks on the perf team (maybe Bas or mstange) have been looking at early-pageload stuff at some point in the not-too-distant past here, so they might have some best-practice suggestions for how we could address this.
|
||
Updated•4 years ago
|
| Comment hidden (off-topic) |
|
||
Updated•2 years ago
|
|
||
Comment 25•2 years ago
|
||
Sorry, there was a problem with the detection of inactive users. I'm reverting the change.
|
||
Comment 26•4 months ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
|
||
Updated•4 months ago
|
Description
•