Closed Bug 1552012 Opened 1 year ago Closed 1 year ago

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)

defect

Tracking

()

RESOLVED DUPLICATE of bug 1561089
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)

  1. Open a new tab (viewing about:home)
  2. Type http://sso.mozilla.com into the URL bar and hit enter.
  3. After the pageload completes: navigate back to about:home (w/ back button or Alt+LeftArrow)
  4. 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

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.

  1. 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.)

Attached video screencast of bug
Flags: needinfo?(nika)

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!
Summary: sso.mozilla.com is shown with broken padlock (insecure), If I navigate "back" to new-tab-page and then forward → Sites that redirect from HTTP->HTTPS are shown with broken padlock (insecure), If I navigate "back" to new-tab-page and then forward

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.)

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.)

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.

We're turning this off on beta in bug 1554217.

Priority: -- → P2

I just tested and this no longer reproduces with my patch from bug 1561089.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1561089

Thanks! Probably no reason to keep the ni=nika open then.

Flags: needinfo?(nika)
You need to log in before you can comment on or make changes to this bug.