Closed Bug 1394698 Opened 2 years ago Closed 2 years ago
Page rendering differs between nightly and beta/release
The problem is only on Nightly build. Reproducible: always Steps To Reproduce: 1. Open https://www.janbambas.cz/links/ Actual Results: Button color is red Expected Results: Button color is gray Regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=689f6fee184628d3dd968e3b6518cc811cfb3e43&tochange=e1b0aaa20f1098b08537b2e13f9e97ee9759d4c7 Suspect: Bug 1246540
Indeed, setting security.mixed_content.use_hsts=false fixes the problem on Nightly build.
I think that nightly only preferences is a factor contributing to increasing regression in release.
(In reply to Alice0775 White from comment #0) > The problem is only on Nightly build. > > > Reproducible: always > > Steps To Reproduce: > 1. Open https://www.janbambas.cz/links/ > > > Actual Results: > Button color is red > > > Expected Results: > Button color is gray > This is interesting! Those buttons are inside an iframe that I load via https from the main document, but the iframe refers css and js (from the same domain) via plain http. This iframe is a static page not under control of the Wordpress installation that I've recently updated to https, which also included css/js references from wordpress controlled html (inspect the source of /links/) to be via https. Only document responses have strict-transport-security: max-age=31536000; includeSubDomains response header. There are no redirects to https generated by the site when you request a script via plain http. So, what is the interesting thing here? Since we've already received response for the root document (/links/ in this case) we must have an HSTS entry for www.janbambas.cz in the strict security database. Hence, I would expect that the iframe referenced css/js would automatically be upgraded by necko to https as part of the HSTS logic. This should work independently of bug 1246540, IIUC! (And - *red* is the expected color of the buttons, actually...) > > Regression window: > https://hg.mozilla.org/integration/mozilla-inbound/ > pushloghtml?fromchange=689f6fee184628d3dd968e3b6518cc811cfb3e43&tochange=e1b0 > aaa20f1098b08537b2e13f9e97ee9759d4c7 > > Suspect: Bug 1246540
Note that https://www.janbambas.cz/moz/board.php (the iframe content) does NOT response with any strict-transport-security headers.
Yes, security.mixed_content.use_hsts=false would prevent the css and js in the iframe from loading since it changes the order of mixed-content/HSTS evaluation, and css and js are both blockable. This is expected behavior for HSTS priming.
This appears to be intended behavior for HSTS priming. If we're going to turn off HSTS priming in nightly that would be a different bug, and we already have a bug to ship HSTS priming (though it's looking like we might not at this point). When we reach a decision eventually nightly and release will match, one way or the other.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.