Within Bug 1633743 we are considering auto upgrading in Nightly, this one is meant for release.

Are there any plans to ship this? It's been shipping in Chrome for >6 months now.

(In reply to estark37 from comment #1)

Are there any plans to ship this? It's been shipping in Chrome for >6 months now.

Hey Emily, thanks for reaching out. There are no real plans to ship mixed content auto upgrading at this point - for now we are going to disable even in Nightly (see Bug 1703847). It's on our radar though and we keep evaluating pros and cons.

This is now breaking images on ASUS's site, and users are noticing the "insecurity" of Samsung sites but thinking it's a Firefox issue. I think we should revisit this before it becomes a webcompat issue too big for us to ignore.

This is going to be a topic at TPAC 2022. I'm not sure why we backed off of it even in Nightly (e.g. bug 1703847). Possibly because we thought "HTTPS-only" would be a better (more secure) solution? But that breaks enough stuff that it requires some fiddly UI bits so users can override and therefore is likely to remain "opt-in". We should reconsider doing this.

can't needinfo Christoph so I'll assign it to him for re-triage :-)

Currently security.mixed_content.block_display_content is set to false but I agree, we should enable this feature in Nightly again. We are definitely interesting in shipping this eventually.

Tom I think we are interested in investing in this feature. Is this something you are interested in?

Looks like this is basically "mixed content level 2"?

(In reply to Frederik Braun [:freddy] from comment #9)

Looks like this is basically "mixed content level 2"?

Correction, security.mixed_content.upgrade_display_content is level 2.

Hi Tomer! Freddy said you would probably be looking into shipping mixed content blocking.

Kind of.
security.mixed_content.upgrade_display_content seems like mixed content level 2.
Only thing differs for now is that the flag is upgrading also same-host iframes and scripts which is not included in mixed content level 2 (since these are active subresources).

https://hg.mozilla.org/mozilla-central/rev/bf2033f42e0f

The landed patch is test-only. Is this bug really fixed?

@Tomer: If this was the last test case needing a fix, please flip the pref for nightly and early beta.

Backed out for causing wpt failures on element-audio.https.sub.html

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | /fetch/metadata/generated/element-audio.https.sub.html | sec-fetch-site - HTTPS downgrade-upgrade, no attributes - promise_test: Unhandled rejection with value: object "Error: Failed to query for recorded headers."

I somehow missed that.
But actually it seems like a normal site effect of Mixed content level 2.

I have to take some more time to understand the failing subtest.

Backed out for causing causing mochitest failures on browser_103_preload.js

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | netwerk/test/browser/browser_103_preload.js | test_103_preload_insecure_cor: unexpected amount of normal request made expected 1 ({"hinted":0,"normal":1}), got 0 ({"hinted":0,"normal":0}) - false == true - JS frame :: resource://testing-common/early_hint_preload_test_helper.jsm :: request_count_checking :: line 34

I looked into the new failure. The latest try push was apparently not uplifted since December 3rd and thus a new test wasn't caught. The test requires loading images over HTTP and HTTPS, which is behavior that we are changing with this patch.

Given that the new test for early-hints does not require and is not written with Mixed Content Lvl2-related HTTP->HTTPS upgrades for images, I would recommend disabling the pref in the browser_103_preload.js, to keep the expected behavior for that test.

There are apparently no other test failures in the push above. I recommend relanding with that fixed.

https://hg.mozilla.org/mozilla-central/rev/2d5ad10a5df3

(In reply to Pulsebot from comment #26)

Pushed by fbraun@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2d5ad10a5df3
enable mixed content level 2 in beta and nightly.
r=freddyb,necko-reviewers,kershaw

Should that be mentioned in our Nightly release notes?

(In reply to Pascal Chevrel:pascalc from comment #28)

Should that be mentioned in our Nightly release notes?

Yes! We'll keep on Nightly for another cycle before we let it ride the trains though.

We have nightly-only release notes, release notes addition process is documented at https://wiki.mozilla.org/Release_Management/Release_Notes#Nomination_in_Bugzilla

Bug 1787576 was marked as duplicate of this one but the change did not fix bug 1787576. Is that expected?

bug 1787576 shouldn't be marked as duplicate IMO. Since this bug is about enabling mixed content display upgrading, the other one is about the interaction of csp and this pref.

This patch does not fix bug 1787576.
Thanks for pointing it out, probably there should be a decision regarding bug 1787576 if it should be fixed or not. So far as I understand the discussion in bug 1787576 the unpleasant outcome is expected behavior and because of that it was marked as "resolved".
But for sure we should keep an eye on such problems since it could lead to complains by users.

Release Note Request (optional, but appreciated)
[Why is this notable]: This feature is upgrading mixed display content (audio, img and video) to https if possible, otherwise the content gets blocked.
[Affects Firefox for Android]: No
[Suggested wording]: Mixed content upgrading of display content
[Links (documentation, blog post, etc)]:

• https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content#upgrading_mixed-display_resources
• https://www.w3.org/TR/mixed-content/

Note added to our 110 nightly notes (only). Thanks.