1949491 - stackoverflow.com - Redirects to login page when trying to access the full inbox

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect, P1)

Description

[Calin Tanase]

Attachment: full inbox FF vs Chrome.mp4

Environment:
Operating system: OnePlus 6 A6000 (Android 11)
Firefox version: Nightly 137.0a1-20250218205441

Preconditions:
• Clean profile
• Must be logged in

Steps to reproduce:

1. Go to https://stackoverflow.com
2. Tap on the inbox/notifications button in the header.
3. Tap on "Go to full inbox" button located at the bottom of the inbox menu.

Expected Behavior:
Redirected to the inbox page.

Actual Behavior:
Redirected to login page.

Notes:

1. Screenshot attached
2. Reproducible regardless of the ETP status
3. Reproducible on Firefox Release as well
4. Not reproducible on Chrome
5. Issue found during WebCompat team [Top100] websites testing

Comment 1

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

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 2

[Dennis Schubert [:denschub]]

They're redirecting to a different domain, but it's signed in in Chrome, so this might be something Cookie related.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

I can repro on android and Windows, so it's not android only.
Ed: can you look at the cookies? Perhaps it has to do with 3pcc or chips?

Comment 4

[edgul]

Some quick notes, still poking around.
I am able to reproduce on today's desktop linux nightly and release 135.
Disabling CHIPS doesn't change anything.
Disabling 3rd party cookie deprecation doesn't change anything.
Disabling ETP doesn't change anything.

If I clear cookies and site data via stackoverflow's address bar, then re-login, then I can no longer reproduce.

Comment 5

[edgul]

I should clarify that in Comment 4 I wasn't clear on HOW I was clearing site data. I've updated this since it matters.

Some more notes about reproduction.

• Note first that there are two login portals one for stackoverflow.com and once for meta.stackexchange.com
• With a fresh profile and login through stackoverflow.com's portal then I can reproduce.
• Clicking on the "go to full inbox" leads to login portal for the site https://meta.stackexchange.com
• If you are not already logged into stackexchange, then you will see the bug here, but once logged in via stackexchange the bug does not reproduce.
• I noted above that that clearing data via stackoverflow's address bar doesn't change that fact.
• however clearing data via stackexchange's address bar DOES, (and we end up back at the reproducible state)
• we can also clear data via about:preferences, which accomplishes the necessary clearing (and then some for other sites) by clearing only "cookies and site data"

So it seems like we are not sending the login cookie to the stackexchange because it's considered 3rd party. Still digging...

Comment 6

[edgul]

Going slowly through the steps to reproduce:

From fresh profile.
Login to stack overflow only.
Note that the cookieDB's raw entry for the login cookie is a PARTITIONED cookie with a stackexchange Domain attribute (samesite=None):

38	^partitionKey=%28https%2Cstackoverflow.com%29	acct	<value>	.stackexchange.com	/	1756156315	1740517915669428	1740517915669428	1	1	0	0	0	2	0

After logging into the stackexchange portal then we note a similar, but UNPARTITIONED cookie:

57 <empty partition>	acct	<value>	.stackexchange.com	/	1756156714	1740518314754910	1740518314754910	1	1	0	0	0	2	0

So again from fresh profile, I login only to stackoverflow and then manually remove the partitionKey entry from the acct cookie for .stackexchange host in the cookie DB and restart firefox,
then the button from stackoverflow "go to full inbox" works!

Still need to look into the desired behaviour:

1. Should the partitionkey have been set at all?
2. Should the browser be sending it anyway?

Comment 7

[edgul]

During stackoverflow login we observe the exchange between stackexchange with:

• network.cookie.cookieBehavior.optInPartitioning = false
• network.cookie.CHIPS.enabled = false

request to stackexchange

Accept image/avif,image/webp,image/png,image/svg+xml,image/;q=0.8,/*;q=0.5
Accept-Encoding gzip, deflate, br, zstd
Accept-Language en-CA,en-US;q=0.7,en;q=0.3
Connection keep-alive
Host stackexchange.com
Origin https://stackoverflow.com
Priority u=5, i
Referer https://stackoverflow.com/
Sec-Fetch-Dest image
Sec-Fetch-Mode cors
Sec-Fetch-Site cross-site
User-Agent Mozilla/5.0 (X11; Linux x86_64; rv:135.0) Gecko/20100101 Firefox/135.0

response from stackexchange

Set-Cookie: acct=some_unique_cookie_value; expires=Mon, 25 Aug 2025 21:58:03 GMT; domain=.stackexchange.com; path=/; secure; samesite=none; httponly

Comment 8

[edgul]

So since this is coming cookie is coming from stackexchange, then we can expect the explicit domain setting to be fine for this.

The problem turns out to be that ETP partitions the cookie. I didn't detect this before because ETP needs to be disabled at the time of "first" login with stackoverflow, not the "second" login with stackexchange. I tested again with CHIPS and optInPartitioning enabled and everything works as expected when ETP cookies are disabled or by site exemption for ETP (provided previous cookies have been removed.

Tim, do you know the best path forward for this?

Comment 9

[Tim Huang[:timhuang]]

We need a shim script here to request storage access when a user tries to log in on stackoverflow.com. I can work on the shim script.

Comment 10

[Tim Huang[:timhuang]]

Attachment: Bug 1949491 - Implement a shim for resolving stackoverflow login issue. r?twisniewski!,#anti-tracking!

Comment 11

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

Set release status flags based on info from the regressing bug 1776760

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3a7ce25019e9
Implement a shim for resolving stackoverflow login issue. r=twisniewski,anti-tracking-reviewers,webcompat-reviewers,bvandersloot

Comment 13

[amarc]

https://hg.mozilla.org/mozilla-central/rev/3a7ce25019e9

Comment 14

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

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

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

For more information, please visit BugBot documentation.

Comment 15

[Tim Huang[:timhuang]]

Tom, should we uplift the fix? I am not sure how uplift works for the WebCompat extension.

Comment 16

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1949491 - Implement a shim for resolving stackoverflow login issue.

Comment 17

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: Signed-in StackOverflow users will not be able to access their full inbox.
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: 1) Visit https://stackoverflow.com 2) Click the inbox/notifications button in the header 3) Click on "Go to full inbox" button located at the bottom of the inbox menu 4) Verify that it works, and does not redirect to the login page.
• Risk associated with taking this patch: low
• Explanation of risk level: Only affects login on StackOverflow, and only contains changes to the webcompat built-in addon.
• String changes made/needed: none
• Is Android affected?: yes

Comment 18

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/db7b363bd265