Unified Trust Panel breaks http-only sites when HTTPS-Only is enabled
Categories
(Firefox :: Address Bar, defect, P1)
Tracking
()
People
(Reporter: dveditz, Assigned: daleharvey)
References
(Regression)
Details
(Keywords: regression, Whiteboard: [sng])
STR:
- Enable the Trust Panel and enable HTTPS-Only
- if necessary, clear any HTTPS-only exceptions from the test sites
2a. click on link to http://http.rip (http link to http-only site)
2b. click on link to https://http.badssl.com (https link that redirects to http-only site)
Expected Result:
The "HTTPS-Only Mode Alert" page appears immediately with the ability to "continue to http" or "go back"
Actual Result:
Nothing except a little hover text at the bottom saying "connecting to http.rip".
If you do nothing and wait for the timeout (over a minute, maybe two?) eventually the alert page will show. In practice completely unusable: will appear to be a broken link as far as any user could tell.
This is not yet enabled by default, but it would be a regression from the pref-flip bug 1988726 when that lands. Not sure which dependency of bug 1964725 actually did this, though.
[updated STR 2b to a similar site to fix a broken link]
Updated•8 months ago
|
Comment 1•8 months ago
|
||
:daleharvey, since you are the author of the regressor, bug 1988726, could you take a look? Also, could you set the severity field?
For more information, please visit BugBot documentation.
| Assignee | ||
Updated•8 months ago
|
| Assignee | ||
Comment 2•8 months ago
|
||
Is this related to the trustpanel? With a fresh profile and trustpanel disabled I am seeing the same behaviour and it is unclear what the frontend could possibly doing here to change the behaviour of content loading
| Reporter | ||
Comment 3•7 months ago
|
||
The symptoms only occurred with the trustpanel setting, but I can't reproduce the problem with (2a) http://http.rip/ (2a) in a new profile.
The problem with the (2b) link is that https://scripting.com appears to be down, and the test relied on it redirecting back to http:. Right now this https: link hangs until timeout whether trustpanel is enabled or not. Maybe Dave found an alternate way to host his images securely for his other blogs and was able to drop his hated HTTPS finally.
http://scripting.com/2023/10/22/012515.html
http://scripting.com/2025/03/15.html#a131603
An alternate testing link for (2b) is https://http.badssl.com/
Since this is fine in a fresh profile I'll close this and try to figure out what kind of cached data is screwing up my primary profile.
Updated•7 months ago
|
Description
•