Yes, this seems to be related to Bug 1869995. In both we block insecure subresources on local pages, and it is unclear to the user how to add exceptions for that. In this bug specifically, I can see the following problems with a small testcase that I also attached here: 1. The HTTPS-Only identity pane UI seems broken. When opening the testcase as a local file with HTTPS-Only enabled, you can see that clicking on the small file icon in the address bar displays a drop-down list with an empty value. The value should be either "On", "Off" or "Off temporarily" though. Setting the value to "Off" also doesn't set any exception permissions. 2. Clicking on the "Continue to insecure site" button in the iframe seems to crash the iframe. 3. Manually adding a exception for `file:///<path to>/bug1887796.html` in the HTTPS-Only section of the settings allows the iframe to load, but strangely enough still blocks subresources of that iframe. In my testcase you can see that the stylesheet in the iframe gets blocked by HTTPS-Only. All of these things don't happen when opening the testcase from via a https:// url. There we can correctly add a exception in the identity pane and through the "Continue to insecure site" button in the iframe. In both those cases, a exception for the top-level page will be added. Of course the iframe will still be blocked by mixed content blocking after that, but disabling `security.mixed_content.block_active_content` will make the iframe load completely, including the iframes subresources. So I think for this bug, fixing these three problems would resolve this bug, as the user should then have an easy way to add a top-level exception through the "Continue to insecure site" button. Sidenote: When mixed content blocking blocks a iframe, there seems to be no indication of that to the user, just a white page. That gets especially confusing when the user just allowed the iframe to load for HTTPS-Only mode. Maybe we should do something about that.
Bug 1887796 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Yes, this seems to be related to Bug 1869995. In both we block insecure subresources on local pages, and it is unclear to the user how to add exceptions for that. In this bug specifically, I can see the following problems with a small testcase that I also attached here: 1. The HTTPS-Only identity pane UI seems broken. When opening the testcase as a local file with HTTPS-Only enabled, you can see that clicking on the small file icon in the address bar displays a drop-down list with an empty value. The value should be either "On", "Off" or "Off temporarily" though. Setting the value to "Off" also doesn't set any exception permissions. 2. Clicking on the "Continue to insecure site" button in the iframe seems to crash the iframe. 3. Manually adding a exception for `file:///<path to>/bug1887796.html` in the HTTPS-Only section of the settings allows the iframe to load, but strangely enough still blocks subresources of that iframe. In my testcase you can see that the stylesheet in the iframe gets blocked by HTTPS-Only. All of these things don't happen when opening the testcase from via a [https:// url](https://bug1887796.bmoattachments.org/attachment.cgi?id=9393317). There we can correctly add a exception in the identity pane and through the "Continue to insecure site" button in the iframe. In both those cases, a exception for the top-level page will be added. Of course the iframe will still be blocked by mixed content blocking after that, but disabling `security.mixed_content.block_active_content` will make the iframe load completely, including the iframes subresources. So I think for this bug, fixing these three problems would resolve this bug, as the user should then have an easy way to add a top-level exception through the "Continue to insecure site" button. Sidenote: When mixed content blocking blocks a iframe, there seems to be no indication of that to the user, just a white page. That gets especially confusing when the user just allowed the iframe to load for HTTPS-Only mode. Maybe we should do something about that.
Yes, this seems to be related to Bug 1869995. In both we block insecure subresources on local pages, and it is unclear to the user how to add exceptions for that. In this bug specifically, I can see the following problems with a small testcase that I also attached here: 1. The HTTPS-Only identity pane UI seems broken. When opening the testcase as a local file with HTTPS-Only enabled, you can see that clicking on the small file icon in the address bar displays a drop-down list with an empty value. The value should be either "On", "Off" or "Off temporarily" though. Setting the value to "Off" also doesn't set any exception permissions. 2. Clicking on the "Continue to insecure site" button in the iframe seems to crash the iframe. 3. Manually adding a exception for `file:///<path to>/bug1887796.html` in the HTTPS-Only section of the settings allows the iframe to load, but strangely enough still blocks subresources of that iframe. In my testcase you can see that the stylesheet in the iframe gets blocked by HTTPS-Only. All of these things don't happen when opening the testcase from via a [https:// url](https://bug1887796.bmoattachments.org/attachment.cgi?id=9393317). There we can correctly add a exception in the identity pane and through the "Continue to insecure site" button in the iframe. In both those cases, a exception for the top-level page will be added. Of course the iframe will still be blocked by mixed content blocking after that, but disabling that through "Address Bar Lock Icon > Connection Secure > Disable Protection for now" will make the iframe load completely, including the iframes subresources. So I think for this bug, fixing these three problems would resolve this bug, as the user should then have an easy way to add a top-level exception through the "Continue to insecure site" button. Sidenote: When mixed content blocking blocks a iframe, there seems to be no indication of that to the user, just a white page. That gets especially confusing when the user just allowed the iframe to load for HTTPS-Only mode. Maybe we should do something about that.