1885949 - First twitch.tv log in fails in private windows due to HTTPS-First and in normal windows since dom.security.https_first_schemeless was enabled

Status: VERIFIED FIXED

(Core :: DOM: Security, defect, P3)

Description

[Kestrel]

STR:

1. Clear all cookies and restart the browser.
2. Visit twitch.tv and attempt to log in with a random username & password.

Expected:
"This username does not exist." quickly appears.

Actual:
"Your browser is not currently supported." appears after some delay.

Reloading page allows log in to work until clearing cookies and restarting.

Does not happen with dom.security.https_first_schemeless = false.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=60c35d4b7fc7e53ca892030e14d775d108f1cbf8&tochange=634166177399b328d66e1e183a4ff52c92551cfe

Regressed by Bug 1863281.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

:mjurgens, since you are the author of the regressor, bug 1863281, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

[Malte Jürgens [:maltejur]]

Thanks for reporting, I can confirm this behavior. From my current observations, this is only happening if the server is responding with a error code on a subresource (in my case 429 too many requests on a graphql request). For some reason HTTPS-First thinks that it upgraded that subresource load (which it shouldn't have, because only schemeless HTTPS-First is enabled, and even normal HTTPS-First doesn't upgrade subresources). That means that HTTPS-First will "downgrade" that load again, as it received an error from the server, and it thinks that error was caused by a upgrade. That downgraded HTTP request is then being blocked by mixed content protection, which seemingly makes twitch display "Your browser is not currently supported".

The good news is that, from my understanding, we aren't actually preventing any logins to Twitch, but just "masking" the actual error (too many requests). But this is still very wrong behavior which will probably also cause issues elsewhere, so it should be fixed as soon as possible.

Comment 3

[Malte Jürgens [:maltejur]]

Attachment: Screenshot_20240319_095819.png

Comment 4

[Malte Jürgens [:maltejur]]

Attachment: Bug 1885949 - Do not copy over HTTPS-First upgrade flag into new loadinfo r?freddyb,simonf!,#necko-reviewers!

Comment 5

[Malte Jürgens [:maltejur]]

Due to another, seemingly unrelated, change in the HTTPS-First loop detection logic (https://phabricator.services.mozilla.com/D204369) that landed a few days ago, this issue is actually no longer present. That patch removed the check for the HTTPS_ONLY_UPGRADED_HTTPS_FIRST flag we accidentally copy into the subresource loadinfo. I'll still leave this bug open for now, because I think we shouldn't copy that flag regardless, and also because I want to add a test for this.

Comment 6

[Malte Jürgens [:maltejur]]

Hm, I take back my last comment, the issue seems to lie somewhere else. I don't see the issue anymore in a local build of todays mozilla-central, but reverting D204369 also doesn't bring it back. Additionally, the check in D204369 was removed in ShouldUpgradeHttpsFirstRequest and not PotentiallyDowngradeHttpsFirstRequest, so it should not matter.

Comment 7

[Frederik Braun [:freddy]]

Does that bug also affect HTTPS-First mode (which is enabled by default in private browsing)?

Comment 8

[Malte Jürgens [:maltejur]]

Yes, it is reproducible for me in 123.0.1 Release with PBM

Comment 9

[Kestrel]

Release is currently affected in private windows unless changing dom.security.https_first_pbm = false.

Regressed by Bug 1716991.

Comment 10

[Donal Meehan [:dmeehan]]

:mjurgens the patch attached here is reviewed. Do you aim to land it shortly?
Wondering if this will be safe to uplift, or should it ride the train with Fx127?

Comment 11

[Malte Jürgens [:maltejur]]

:dmeehan yes, I will land it now. Sorry about the delay, I was out of office the last days and before that didn't want to land because of the freeze. I think this should be uplifted, and I will request to do so in about a week when this patch doesn't cause any problems in Nightly.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/28b2b5bfbed5
Do not copy over HTTPS-First upgrade flag into new loadinfo r=necko-reviewers,freddyb,simonf,jesup

Comment 13

[Noemi Erli[:noemi_erli]]

Backed out changeset 28b2b5bfbed5 (Bug 1885949) for causing http related mochitest failures CLOSED TREE

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&collapsedPushes=842382&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=28b2b5bfbed52785c57ab51bdc7f6b5d62b13003&searchStr=http2

Log: https://treeherder.mozilla.org/logviewer?job_id=454866488&repo=autoland&lineNumber=2132

Backout: https://hg.mozilla.org/integration/autoland/rev/45015ee8ccea091465ea87b6c3ae7d84a3dc9150

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e713aef26079
Do not copy over HTTPS-First upgrade flag into new loadinfo r=necko-reviewers,freddyb,simonf,jesup r=reland

Comment 15

[Iulian Moraru]

We found the actual revision that caused the failures and this is now re-landed. Sorry for any inconvenience caused by the backout.

Comment 16

[Aron Cseh]

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

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:mjurgens, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox126 to wontfix.

For more information, please visit BugBot documentation.

Comment 18

[Malte Jürgens [:maltejur]]

[Tracking Requested - why for this release]:
This patch fixes a issue with HTTPS-First mode, which surfaces both through the schemeless HTTPS-First mechanism enabled in Nightly, and through HTTPS-First being generally enabled in PBM in Release and ESR. This issue isn't severe, as it only affects very specific server responses which already an error status code. But it is causing web compatibility issues on a prominent site (twitch.tv), and possibly others.

Comment 19

[Donal Meehan [:dmeehan]]

:mjurgens this could be uplifted for Fx126 but it will need an uplift request for beta - see https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift
Or someone on your team could support you.
There are two regressor bugs - Bug 1863281 mentions dom.security.https_first_schemeless which is only enabled in early beta.
Can you confirm ESR115 is actually affected?

Comment 20

[Malte Jürgens [:maltejur]]

Yes, I can confirm that this is actually also affects ESR115. This is a problem with HTTPS-First in general, which is enabled by default in ESR in private browsing mode. Bug 1863281 is marked as a regressor, as it makes the issue also appear in normal browsing.

I will request a uplift for beta (and possibly esr) next week when the patch has been in Nightly for a few days.

Comment 21

[Malte Jürgens [:maltejur]]

Attachment: Bug 1885949 - Do not copy over HTTPS-First upgrade flag into new loadinfo

Original Revision: https://phabricator.services.mozilla.com/D205048

Comment 22

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: Some users in PBM may see confusing "Your browser is not currently supported" error messages on the twitch.tv login page when they should receive another error message
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: Follow the STR in https://bugzilla.mozilla.org/show_bug.cgi?id=1885949#c0
• Risk associated with taking this patch: Low
• Explanation of risk level: The patch is not complex and has sat in Nightly for a few days now without any problems. Additionally, a lot of the HTTPS-First behaviour is covered by automated testing.
• String changes made/needed: -
• Is Android affected?: yes

Comment 23

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/7d0f32ab9f83

Comment 24

[Ryan VanderMeulen [:RyanVM]]

Is this ready for an ESR uplift request?

Comment 25

[Malte Jürgens [:maltejur]]

Attachment: Bug 1885949 - Do not copy over HTTPS-First upgrade flag into new loadinfo

Original Revision: https://phabricator.services.mozilla.com/D205048

Comment 26

[Phabricator Automation]

esr115 Uplift Approval Request

• User impact if declined: Some users in PBM may see confusing "Your browser is not currently supported" error messages on the twitch.tv login page when they should receive another error message
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: Follow the STR in https://bugzilla.mozilla.org/show_bug.cgi?id=1885949#c0
• Risk associated with taking this patch: Low
• Explanation of risk level: The patch is not complex and has caused no problems in Nightly or Beta in the last weeks. Additionally, a lot of the HTTPS-First behaviour is covered by automated testing.
• String changes made/needed: -
• Is Android affected?: yes

Comment 27

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/36d2dde06733

Comment 28

[bhidecuti]

I was unable to reproduce the issue while following the steps described in Comment 0, but I was able to replicate the issue on an affected Firefox Nightly 126.0a1 build from (2024-03-18), under macOS 12.6.6 and Windows 11 as follows:

• launch Firefox with a new profile, go to twitch.tv and attempt to log in with a random username and password
• go to twitch.tv while in PBM mode and attempt to log in with a random username and password (managed to reproduce on Firefox Release 125.0.3 as well)

Verified as fixed on on Firefox 115.11.0esr build ID 20240506144012, Firefox 126.0 RC build ID 20240506203248 and on Firefox Nightly 127.0a1 build ID 20240507214419, using macOS 12.6.6 / macOS 13.6.1, Windows 11 and Ubuntu 22.04.
"This username does not exist." / "That password was incorrect. Please try again." error message is displayed after attempting to log in with a random username and password while following the steps mentioned above.

@ke5trel, since I was unable to reproduce the issue with the steps described in Comment 0, could you please verify that you are no longer able to reproduce the issue? Thank you in advance!

Comment 29

[Kestrel]

@bhidecuti, your steps to reproduce the issue sound sufficient.

I cannot reproduce it on the latest Nightly 127.0a1 (2024-05-07) or latest Beta 126.0b9 with a normal/private window.

Comment 30

[bhidecuti]

Thank you for the verification, Kestrel!
Based on Comment 28 and Comment 29 I am marking this verified as fixed.