1709483 - Cannot log in to twitter in a private tab

Status: RESOLVED DUPLICATE of bug 1701303

(Core :: DOM: Navigation, defect, P1)

Description

[Kevin Brosnan [Ex-Mozilla]]

From github: https://github.com/mozilla-mobile/fenix/issues/19318.

Site with issue and any steps to reproduce

twitter.com in Private Browsing Mode

Expected behavior

1. Log in to Twitter in a Private Tab

Actual behavior

1. After logging in, you either
   • (if you don't use 2FA) Get a "Something went wrong [Retry]" UI
   • (if you use 2FA) After giving your authenticator code, you get booted back to the login flow

Does toggling Tracking Protection fix the issue? (Press the shield icon in the toolbar while on the site to see toggle)

No. Though it's hard to say if it would work because it doesn't maintain its settings in PBM and Twitter can't figure out which domain it wants to be.

Can you reproduce in Chrome (or other non-Mozilla browser)?

Does not reproduce in non-Private tabs on Fenix.

Device information

• Android device: Samsung A5
• Fenix version: 90.0a1 2015807419

Change performed by the Move to Bugzilla add-on.

Comment 1

[Kevin Brosnan [Ex-Mozilla]]

With mozregression --app gve's help I got the following pushlog with the STR being "Check 'Private Browsing'. Load twitter.com. Log in. Provide username and password. Presented with 'Something Went Wrong [Retry?]'": https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e2241700c420dcd4f4420a7cc61a352e6abc1ed9&tochange=f9628f3c1fe087d98d4f3c2a2f1bb3bb8ed428e4

@kbrosnan Anything else I can help with?

Aaron do you think you are the best person to address this because of bug 1703968 or my other suspects are Nika Layzell — Bug 1702714 or maybe Iain Ireland — Bug 1701787 the rest are backouts or UI changes for desktop.

Tracking Requested - why for this release: Regression

Comment 2

[(No longer employed by Mozilla) Aaron Klotz]

I'll take a look to start with, at least to troubleshoot.

Comment 3

[(No longer employed by Mozilla) Aaron Klotz]

Keeping myself on ni?

Comment 4

[Pascal Chevrel:pascalc (PTO until April 26)]

Kevin, does that happen with Fenix 89 beta? The description in comment #0 suggests that this regression was noticed on Nightly 90

Comment 5

[Kevin Brosnan [Ex-Mozilla]]

I was going by the commit data. The regression range pointed to commits from April 9th which was when nightly was on 89.

Comment 6

[Pascal Chevrel:pascalc (PTO until April 26)]

My question is actually to know if this is happening in beta where experimental platform stuff is largely disabled. If this is a nightly-only regression, I don't need to track its resolution for our 89 release.

Comment 7

[Chris H-C :chutten]

I tried to reproduce it three times using Firefox for Android Beta (89b4) just now, and it works just fine. (ie, I can log into Twitter even in a Private Tab)

Comment 8

[(No longer employed by Mozilla) Aaron Klotz]

Thanks Chris! I was actually going to ask somebody to try that! :-)

Indeed, assuming that COOP+COEP for GeckoView is the culprit, it is not enabled past Nightly.

Comment 9

[(No longer employed by Mozilla) Aaron Klotz]

The main symptom is that our cookies for Twitter (including the auth token) are disappearing into thin air.

Further investigation has revealed that this is not a cookie issue, but a docshell issue. During the login sequence, we reach zero private docshells at one point, which signals to Gecko that it should go ahead and clear the private browsing session... but then we start another private docshell (presumably as a result of a process switch?) and try to finish logging in!

An easy way to work around this is to have other private tabs open while logging in to Twitter from a private tab -- since the private docshell count never reaches 0, the private browsing session is never cleared out, and the Twitter login succeeds.

I'm going to start looking into how we're managing this stuff on the GeckoView side...

Comment 10

[(No longer employed by Mozilla) Aaron Klotz]

AFAICT this is effectively a race condition involving various pieces that are running asynchronously:

Let's suppose that we have (and only have) content process c1 hosting a private docshell.

1. A navigation occurs, and the parent process decides that a process switch is necessary.
2. CanonicalBrowsingContext::ChangeRemoteness creates a new content process, c2, which is successfully starting up asynchronously.
3. c1's docshell is shut down, and now there are no more private docshells in that process. It sends PrivateDocShellsExist(false) to the parent.
4. ContentParent removes c1 from ContentParent::sPrivateContent.
5. sPrivateContent is now empty, because while a ContentParent exists for c2, it has not completed startup yet, and thus no PBrowser activity has occurred yet. c2 is not yet considered to be hosting private content, as its startup is still in flight!
6. ContentParent fires "last-pb-context-exited" and the private browsing session is blown away.
7. c2 completes, the process switch completes, but it is now using a new private browsing session that is missing all the data from the previous one.

Comment 11

[Nika Layzell [:nika] (ni? for response)]

(In reply to Aaron Klotz [:aklotz] from comment #10)

AFAICT this is effectively a race condition involving various pieces that are running asynchronously:

Yup, that is also my parse of this. I think this should probably be fixed by switching to using BrowsingContexts for tracking whether we have private contexts directly from the parent process, rather than using the legacy e10s mechanism with PrivateDocShellsExist. This should probably just require moving AffectPrivateSessionLifetime to CanonicalBrowsingContext and doing the incrementing & decrementing from ::Attach and ::Detach when in the parent process. I don't think we'll need to expose any of this information to a content process at all.