[e10s] Gmail tab is restored as a blank tab

RESOLVED DUPLICATE of bug 1114040

Status

()

Firefox
Session Restore
RESOLVED DUPLICATE of bug 1114040
3 years ago
3 years ago

People

(Reporter: mossop, Assigned: mossop)

Tracking

unspecified
x86
Mac OS X
Points:
3
Bug Flags:
firefox-backlog +
qe-verify -

Firefox Tracking Flags

(e10s?)

Details

(Assignee)

Description

3 years ago
The tab for my personal gmail account isn't restored correctly when in e10s mode. Everytime an about:newtab is restored instead. I used TabState.collect in a running session and confirmed that the session data it returns for the tab just includes a single about:newtab entry. This is reproducible in a clean profile.
Flags: firefox-backlog+
(Assignee)

Comment 1

3 years ago
When navigating from the non-remote about:newtab page to the remote mail.google.com page we effectively do a session restore then fire off a new page load. So we set __SS_data on the browser then restore the history then send SessionStore:restoreTabContent to load the new page. From here we wait for two things:

A webprogress listener waits for the end of the network traffic then sends SessionStore:restoreTabContentComplete, this calls _resetLocalTabRestoringState which clears out some of the SS data about the tab including the browser's epoch.

A DOM load event listener waits for the top-level document to load then sends SessionStore:restoreDocumentComplete which clears __SS_data from the browser.

If the webprogress event fires first then the parent has forgotten the browser's epoch by the time it receives SessionStore:restoreDocumentComplete and so doesn't clear __SS_data from the browser, after that any attempt to call TabState.collect returns the old __SS_data which is just the about:newtab entry.

This can happen in a few cases:

If the attempt to load the page being restored throws an exception then we send these messages in the bad order: http://hg.mozilla.org/mozilla-central/annotate/912036eeb024/browser/components/sessionstore/content/content-sessionStore.js#l148. This is probably rare.

The case I'm hitting is that the URL being loaded redirects to a new URL. This causes the progress listener to see the network traffic end for the first request but no load event first until the second request is nearly complete. This is going to be more common with bug 1075658 but it should be possible to reproduce if you session restore a URL that changes from loading normally to redirecting the next time you open the browser.
(Assignee)

Comment 2

3 years ago
One minor correction, for a regular HTTP redirect everything is fine, however if the loaded page calls window.location.replace before the load event fires then that is when everything goes wrong, the current load is cancelled with NS_BINDING_ABORTED and the load event for that page never first, then a new network request starts for the new page.
(Assignee)

Comment 3

3 years ago
I have an automated test to verify this, now I just need to figure out how to fix it ...
Points: --- → 3
Flags: qe-verify-
Great! Want to work on the test in bug 1114040? :)
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1114040
You need to log in before you can comment on or make changes to this bug.