Bugzilla

(In reply to Daniel Veditz [:dveditz] from comment #0)
> If https-only is turned on and we're unable to upgrade a framed http: site, we show the "HTTPS-Only Mode Alert" error page. I don't think we want to do that because normally the mixed-content blocker would block that document with no fuss (other than a console log error).

I think I agree with that. We would still need to keep the logic for the error page though, as users can opt out of mixed content blocking per site via the lock icon in the address bar, and then we would still want this error page. I will ask Christoph if he knows about any edgecases because of which we currently still display this error page with mixed content blocking enabled, but I suspect we just behave this way because afaik HTTPS-Only predates mixed content blocking.

Alternatively, we could also consider just dropping the option to exempt the top-level page from inside the iframe entirely, even with mixed content blocking disabled. That would make things a lot simpler for us, and may also help fix some other edgecases like the one in Bug 1887796. Users could then still disable HTTPS-Only for the top-level page via the lock icon, like they already have to do for other subresources like images. We could possibly also consider automatically adding a HTTPS-Only exception for the subresources if the user manually disables mixed content protection on a site through the lock icon.

> A framed site could try to get its framer exempted, which might make it look broken if it was relying on https-only?

Note that due to permission implementation quirks, it can only exempt subresources of its framing top-level page (which with mixed content blocking means basically nothing). This is due to the exemption being added for the https:// principal of the top-level site, while regular HTTPS-Only exemptions have a http:// schemes (because that is the scheme that URLs of top-level loads have when HTTPS-Only needs to check if they are exempted).

Can you also CC me on Bug 1888695 you mentioned Dan?

(In reply to Daniel Veditz [:dveditz] from comment #0)
> If https-only is turned on and we're unable to upgrade a framed http: site, we show the "HTTPS-Only Mode Alert" error page. I don't think we want to do that because normally the mixed-content blocker would block that document with no fuss (other than a console log error).

I think I agree with that. We would still need to keep the logic for the error page though, as users can opt out of mixed content blocking per site via the lock icon in the address bar, and then we would still want this error page. I will ask Christoph if he knows about any edgecases because of which we currently still display this error page with mixed content blocking enabled.

Alternatively, we could also consider just dropping the option to exempt the top-level page from inside the iframe entirely, even with mixed content blocking disabled. That would make things a lot simpler for us, and may also help fix some other edgecases like the one in Bug 1887796. Users could then still disable HTTPS-Only for the top-level page via the lock icon, like they already have to do for other subresources like images. We could possibly also consider automatically adding a HTTPS-Only exception for the subresources if the user manually disables mixed content protection on a site through the lock icon.

> A framed site could try to get its framer exempted, which might make it look broken if it was relying on https-only?

Note that due to permission implementation quirks, it can only exempt subresources of its framing top-level page (which with mixed content blocking means basically nothing). This is due to the exemption being added for the https:// principal of the top-level site, while regular HTTPS-Only exemptions have a http:// schemes (because that is the scheme that URLs of top-level loads have when HTTPS-Only needs to check if they are exempted).

Can you also CC me on Bug 1888695 you mentioned Dan?