1362190 - [Intermittent] clicking manage account link in sync preferences ask logged in user to sign in

Status: RESOLVED DUPLICATE of bug 1308038

(Cloud Services :: Server: Firefox Accounts, defect)

Description

[Kanchan Kumari QA]

STR:
1. Sign in to Firefox Account.
2. Wait a couple minute after sync gets finish.
3. In hamburger menu, click to FxA icon to open sync preference
4. In sync preference, click 'Manage account' link.

Expected: It should open FxA setting page 

Actual: It asks user to sign in to FxA to continue.

Please see video here: https://ranisharma22.tinytake.com/sf/MTU3NTAwN181NDAyNDI4

I could reproduce this issue 3-4 times in a row.

Comment 1

[Mark Hammond [:markh] [:mhammond]]

Thanks Kumar - in bug 1353571 you mentioned this might be a regression from that bug, but I doubt it is. We know there are a few issues related to this, but IIRC, they tend to be around either private-browsing, or when Firefox is set to never remember history - but in those cases I believe it is always reproducible.

Shane, does this ring a bell to you?

Comment 2

[Kanchan Kumari QA]

This is to confirm that in this case it was neither private-browsing nor 'Never remember history'.

Today again I encountered this issue multiple times on FxA custom test environment while testing 'Secondary email' feature.

Comment 3

[Ryan Kelly [:rfkelly]]

This will likely be fixed by the Firefox patch Shane is working on in Bug 1308038.

It sounds like this may be related to the way localStorage is handled in multi-process Firefox; if you disable multi-process Firefox does the problem stop occurring?

Comment 4

[Kanchan Kumari QA]

I couldn't reproduce this issue on the latest nightly today with multi-process on.

I hit this bug again on custom testing environment where multi-process is disable.
STR:
1. confirm sign-in through email
2. In hamburger menu, click to FxA icon to open sync preference - here it shows user is signed in.
3. In sync preference, click 'Manage account' link.

Observation: It asks user to sign in to FxA to continue, and this time hamburger menu too shows user as not signed-in/disconnected sync.  

Earlier as shown in video of bug report, sync wasn't getting disconnected.

Comment 5

[Shane Tomlinson [:stomlinson]]

:markh - PB mode was always a problem, E10s was intermittent. I was able to reproduce 100% of the time in Nightly the other day after Ryan Feeley showed it happening on his machine. I wonder if this is a manifestation of [1]. I haven't been able to find the bug where DOM storage in FxA embedded in about:accounts seems to be totally isolated from FxA's DOM storage in a normal tab.

[1] - https://bugzilla.mozilla.org/show_bug.cgi?id=666724

Comment 6

[Shane Tomlinson [:stomlinson]]

Ref https://bugzilla.mozilla.org/show_bug.cgi?id=1286798

Comment 7

[Mark Hammond [:markh] [:mhammond]]

(In reply to Shane Tomlinson [:stomlinson] from comment #5)
> I haven't been able to find the bug where DOM storage in FxA embedded in
> about:accounts seems to be totally isolated from FxA's DOM storage in a
> normal tab.

I bet that's because about:accounts is in the parent process (and maybe fallout from that new DOMStorage impl).  Paul and I were just chatting about this same general issue WRT the benefits/tradeoffs of having accounts.firefox.com used in *both* the (ideally sandboxed) child and parent processes, and this bug seems related.

Comment 8

[Andrew Sutherland [:asuth] (he/him)]

Saw the see also on bug 666724.  Bug 1285898 covered e10s support for localStorage, and you might be running up against a broadcast asymmetry limitation with the fix that landed that was discussed in bug 1285898 comment 5 but regrettably not addressed.  Specifically, "LocalStorage writes to an origin in the parent will be broadcast to children and they will see the change.  The opposite is not true."  Prior to that fix landing, each process would be its own localStorage island whose writes would hit the DB but would not see the writes of other processes unless all users of localStorage for the origin closed and the 20-second keepalive timed out... and then the origin was loaded again.

From comment 7 it sounds like you're using localStorage for the same origin in both the parent process and in content processes, in which case you are encountering this "limitation".  It wouldn't be particularly difficult to correct this, but it's important to keep in mind that:
- Any use of localStorage by your origin will potentially jank your content process with a sync request to the parent.  There's currently some work on reducing the jank, but jank is jank.
- localStorage has no defined concurrency semantics; the above fix tried hard to keep things as sane as possible, but if you want anything resembling transactions, you need to use IndexedDB.  We'll have IDB observers eventually (bug 1059724) but for the time being BroadcastChannel+IndexedDB is a way better choice than localStorage.  If you absolutely need synchronous access to data at startup, abuse cookies as a storage mechanism, but try and keep your cookies small since they're currently in memory all the time.

Comment 9

[Shane Tomlinson [:stomlinson]]

I'm closing this as a dup of #1308038 which has a patch in progress. Thanks Kanchan and the feedback :asuth!