1394698 - Page rendering differs between nightly and beta/release

Status: RESOLVED WORKSFORME

(Core :: Security, defect)

Description

[Alice0775 White]

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

Comment 1

[Alice0775 White]

Attachment: screenshot

Comment 2

[Alice0775 White]

Indeed, setting security.mixed_content.use_hsts=false fixes the problem on Nightly build.

Comment 3

[Alice0775 White]

I think that nightly only preferences is a factor contributing to increasing regression in release.

Comment 4

[Honza Bambas (:mayhemer)]

(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

Comment 5

[Honza Bambas (:mayhemer)]

Note that https://www.janbambas.cz/moz/board.php (the iframe content) does NOT response with any strict-transport-security headers.

Comment 6

[Kate McKinley [:kmckinley, :Kate]]

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.

Comment 7

[Daniel Veditz [:dveditz] back January 5, 2026]

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.