Sites that redirect from HTTP->HTTPS are shown with broken padlock (insecure), If I navigate "back" to new-tab-page and then forward
Categories
(Core :: DOM: Content Processes, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr60 | --- | unaffected |
| firefox66 | --- | unaffected |
| firefox67 | --- | unaffected |
| firefox67.0.1 | --- | unaffected |
| firefox68 | + | disabled |
People
(Reporter: dholbert, Unassigned)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files)
STR:
0. Start with a fresh profile (not logged in to SSO)
- Open a new tab (viewing about:home)
- Type http://sso.mozilla.com into the URL bar and hit enter.
- After the pageload completes: navigate back to about:home (w/ back button or Alt+LeftArrow)
- Navigate forward (w/ forward button or Alt+RightArrow)
EXPECTED RESULTS: The page URL bar should look as it did in step 2 (it should show a https://auth.mozilla.auth0.com/ URL, which is what sso.m.c redirects to)
ACTUAL RESULTS: The URL bar shows a broken padlock, and its contents are the insecure URL http://sso.mozilla.com (the http:// isn't shown by default, but it's added in the clipboard if you copy the contents of the URLbar).
I suspect/hope we aren't actually doing an insecure load here, so I think this is just UI being broken/confused somehow.
This is a regression -- regression range is https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2b107d251cf5b2344ceb8dfa045a90f160a55b15&tochange=9a8e4a445e0c8eee6b052576f911aa1c4d06cb02 which is just this one commit:
https://hg.mozilla.org/integration/autoland/rev/9a8e4a445e0c8eee6b052576f911aa1c4d06cb02
Nika Layzell — Bug 1528360 - Enable httpResponseProcessSelection by default r=qdot,valentin
| Reporter | ||
Comment 1•7 years ago
|
||
Just as extra verification of the regression-range: if I toggle the httpResponseProcessSelection about:config pref to false in current Nightly, then I get EXPECTED RESULTS. So this is indeed caused by that pref/feature.
| Reporter | ||
Comment 2•7 years ago
•
|
||
- Type http://sso.mozilla.com into the URL bar and hit enter.
NOTE: you probably have to include http:// [not https, and not just the bare domain] in this URL that you type in step 2, or otherwise Firefox might autocomplete to the https version if you've previously visited it.
(I'm pretty sure this bug only happens if you start off with a HTTP URL that redirects to an HTTPS URL. There might be some other special conditions about this SSO redirect that are necessary for the bug, too; I'm not sure yet.)
| Reporter | ||
Comment 3•7 years ago
|
||
| Reporter | ||
Updated•7 years ago
|
| Reporter | ||
Comment 4•7 years ago
|
||
Actually: this affects some web content as well, not just the URLbar!
If I perform the STR with http://google.com/ as my testcase (starting at about:home, typing http://google.com/, and then go back + forward), then:
- the URL bar ends up just showing: (i) google.com
- The huge "Google" logo-image above the search box does not show up -- its alt-text shows instead!
| Reporter | ||
Comment 5•7 years ago
|
||
Here's a screencast of the bug at google.com, with the image not showing up at the end, as described in previous comment.
(I get normal/expected results if I set the httpResponseProcessSelection pref to false.)
| Reporter | ||
Comment 6•7 years ago
|
||
There is something special about starting at the new-tab-page here (about:home), too.
If I start out at an actual web page, or a different about: page, then I can't reproduce the bug. (I tested about:robots, about:firefox, about:config, about:addons, about:support, and about:preferences, and I couldn't reproduce with any of those. But if I start at about:home [either via a fresh tab or by typing about:home manually in an existing tab], then I can reproduce.)
Updated•7 years ago
|
Comment 7•7 years ago
|
||
We already backed this out in 67 thanks to some other issues, and it would be fine to keep httpResponseProcessSelection off in 68 as well, as we haven't had the time/resources to fix the issues yet.
We should disable this pref on beta and stop tracking it. I'll try to look into the specific issue at some point, but haven't had the time to look deeply yet unfortunately.
Comment 8•7 years ago
|
||
We're turning this off on beta in bug 1554217.
Updated•7 years ago
|
Comment 9•7 years ago
|
||
I just tested and this no longer reproduces with my patch from bug 1561089.
| Reporter | ||
Comment 10•7 years ago
|
||
Thanks! Probably no reason to keep the ni=nika open then.
Updated•4 years ago
|
Description
•