1510619 - Gmail in a pinned tab fails to load on browser startup

Status: RESOLVED DUPLICATE of bug 1535674

(Firefox :: Session Restore, defect, P1)

Description

[Jim Mathies [:jimm]]

I have my main gmail in a pinned tab. Every morning when I open up Firefox it displays as a blank white content area. To correct I have to hit ctrl-r to (re)load to display.

Not sure what component this should be in. Filing in fx general for now. Issue doesn't appear to be paint related, more content loading related.

Comment 1

[:Gijs (he/him)]

Are there errors in the browser console? Does the URL show up in the URL bar? Is this a regression, and/or has it been happening for a while?

Comment 2

[Jim Mathies [:jimm]]

Attachment: gmail.jpg

Nothing in the console that looks relevant. Here's the url and tab.

Comment 3

[:Gijs (he/him)]

If you open the devtools inspector, does that show the document has loaded? If it shows any document, and you eval `document.documentURI` in the (web/devtools) js console, what does that produce? about:blank or the same gmail url or something else?

Comment 4

[Mike Conley (:mconley) (:⚙️)]

This might be SessionStore related, or it also might be ServiceWorker related.

jim, just so we're clear, there's nothing in either in the DevTools Console, nor the Browser Console when this occurs?

Comment 5

[Jim Mathies [:jimm]]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #4)
> This might be SessionStore related, or it also might be ServiceWorker
> related.
> 
> jim, just so we're clear, there's nothing in either in the DevTools Console,
> nor the Browser Console when this occurs?

Nothing there afaict.

I haven't seen this in over a week so I'm going to close out as WFM and re-open if I get it again.

Comment 6

[Jim Mathies [:jimm]]

Attachment: blank gmail tab w/inspector

Comment 7

[Jim Mathies [:jimm]]

(In reply to :Gijs (he/him) from comment #3)
> If you open the devtools inspector, does that show the document has loaded?
> If it shows any document, and you eval `document.documentURI` in the
> (web/devtools) js console, what does that produce? about:blank or the same
> gmail url or something else?

documentURI is 'https://mail.google.com/mail/u/0/#inbox'

Comment 8

[:Gijs (he/him)]

(In reply to Jim Mathies [:jimm] from comment #7)
> (In reply to :Gijs (he/him) from comment #3)
> > If you open the devtools inspector, does that show the document has loaded?
> > If it shows any document, and you eval `document.documentURI` in the
> > (web/devtools) js console, what does that produce? about:blank or the same
> > gmail url or something else?
> 
> documentURI is 'https://mail.google.com/mail/u/0/#inbox'

The inspector is basically showing about:blank. It's pretty surprising that the document URI is set to the "right" thing here despite it showing about:blank. Maybe :nika can suggest some next steps to try here? I'm also a bit suspicious of add-ons being involved given some recent discussions with :kmag in bug 1471327 about initial about:blank, but I wouldn't know how to narrow that down further besides suggesting you try running without noscript for a bit, which is probably a bit of a non-starter...

Comment 9

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

(In reply to :Gijs (he/him) from comment #8)
> Maybe :nika can suggest some next steps to try here?

Hmm, so I know that SessionRestore occasionally sets the current URI directly due to stuff like session history and push/popstate.

Next time you have this opened, can you pop open the inspector again, and check what the DOM in the inspector looks like? Immediately I'm thinking this could be one of:

a) We're actually drawing about:blank somehow, which implies that the load messed up in some way, or
b) The remote browser is actually loaded, and there's a DOM inside it, but we're not drawing the xul:browser remote content correctly. (IIRC I've seen some similar bugs in this area around some race conditions I was unable to diagnose).

It would be awesome if you could grab me some screenshots of the Inspector and Console tabs of the web inspector as well.

Finally, I'm curious what happens if you unpin the tab and then drag it into a new browser window. Does the browser re-appear? Does anything appear in the browser console toolbox?

Comment 10

[:Gijs (he/him)]

(In reply to :Nika Layzell from comment #9)
> (In reply to :Gijs (he/him) from comment #8)
> > Maybe :nika can suggest some next steps to try here?
> 
> Hmm, so I know that SessionRestore occasionally sets the current URI
> directly due to stuff like session history and push/popstate.
> 
> Next time you have this opened, can you pop open the inspector again, and
> check what the DOM in the inspector looks like? Immediately I'm thinking
> this could be one of:
> 
> a) We're actually drawing about:blank somehow, which implies that the load
> messed up in some way, or
> b) The remote browser is actually loaded, and there's a DOM inside it, but
> we're not drawing the xul:browser remote content correctly. (IIRC I've seen
> some similar bugs in this area around some race conditions I was unable to
> diagnose).
> 
> It would be awesome if you could grab me some screenshots of the Inspector
> and Console tabs of the web inspector as well.
> 
> Finally, I'm curious what happens if you unpin the tab and then drag it into
> a new browser window. Does the browser re-appear? Does anything appear in
> the browser console toolbox?

attachment 9031129 [details] shows the inspector, which is why I asked - we're actually drawing about:blank, AFAICT...

Comment 11

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

That is super weird... I'm a bit surprised that the scrollbars & resize handle are actually appearing in the inspector TBH...

When performing SessionRestore we do lie about the URI in a way which I believe would affect the |.documentUri| (https://searchfox.org/mozilla-central/rev/49e78df13e7a505827a3a86daae9efdf827133c6/browser/components/sessionstore/ContentRestore.jsm#118-128). This is done when performing the initial setup of the tab before we actually switch to the tab and begin restoring the raw content into it (https://searchfox.org/mozilla-central/rev/49e78df13e7a505827a3a86daae9efdf827133c6/browser/components/sessionstore/ContentRestore.jsm#181-187).

I'm guessing what is happening is that we're never getting to actually call restoreTabContent for this tab, so we have a fake document URL sitting around...



So, when we start restoring a window, we call restoreWindow: https://searchfox.org/mozilla-central/rev/49e78df13e7a505827a3a86daae9efdf827133c6/browser/components/sessionstore/SessionStore.jsm#3409-3421
Pinned tabs never have a lazy browser created for them: https://searchfox.org/mozilla-central/rev/49e78df13e7a505827a3a86daae9efdf827133c6/browser/components/sessionstore/SessionStore.jsm#3503
We then call into restoreTabs, which will call restoreTab on every tab: https://searchfox.org/mozilla-central/rev/49e78df13e7a505827a3a86daae9efdf827133c6/browser/components/sessionstore/SessionStore.jsm#3808-3813
willRestoreImmediately will be false, as the tab isn't selected: https://searchfox.org/mozilla-central/rev/49e78df13e7a505827a3a86daae9efdf827133c6/browser/components/sessionstore/SessionStore.jsm#3830-3831
sendRestoreHistory will be called to run that first pass (which sets .documentUri) immediately in this function: https://searchfox.org/mozilla-central/rev/49e78df13e7a505827a3a86daae9efdf827133c6/browser/components/sessionstore/SessionStore.jsm#3943
forceOnDemand will be false, as we're not restoring a crashed tab, so we'll be adding the tab to TabRestoreQueue: https://searchfox.org/mozilla-central/rev/49e78df13e7a505827a3a86daae9efdf827133c6/browser/components/sessionstore/SessionStore.jsm#3950-3964

Because we're a pinned tab, we should be in the priority queue, meaning we'll prepare a connection & call restoreNextTab which will pop the queue & try to restore it's contents. This won't be the case if browser.sessionstore.restore_pinned_tabs_on_demand is false, which will mean that it shouldn't be restored until selected.
https://searchfox.org/mozilla-central/rev/49e78df13e7a505827a3a86daae9efdf827133c6/browser/components/sessionstore/SessionStore.jsm#4118-4121

If we somehow end up not restoring, it should be restored when selected in onTabSelect
https://searchfox.org/mozilla-central/rev/49e78df13e7a505827a3a86daae9efdf827133c6/browser/components/sessionstore/SessionStore.jsm#2140-2165
The TAB_STATE_FOR_BROWSER should be being set before _sendRestoreHistory: https://searchfox.org/mozilla-central/rev/49e78df13e7a505827a3a86daae9efdf827133c6/browser/components/sessionstore/SessionStore.jsm#3938-3941

I don't see an obvious way this could end up such that the tab is not restored, but there's probably some way to make it happen here.


It'd probably be good to know what the browser.sessionstore.** prefs are set to, and what has ended up logged in the browser console toolbox.

Comment 12

[:Gijs (he/him)]

(In reply to :Nika Layzell from comment #11)
> That is super weird... I'm a bit surprised that the scrollbars & resize
> handle are actually appearing in the inspector TBH...

There's a hidden pref to always show anonymous content which is presumably turned on in this profile.

> When performing SessionRestore we do lie about the URI in a way which I
> believe would affect the |.documentUri|

<snip analysis that'd just end up with broken links; see comment #11; >

> I don't see an obvious way this could end up such that the tab is not
> restored, but there's probably some way to make it happen here.
> 
> 
> It'd probably be good to know what the browser.sessionstore.** prefs are set
> to, and what has ended up logged in the browser console toolbox.

Jim, can you check your session restore prefs?

Mike, any ideas at what's going on here with session restore based on Nika's analysis in comment #11?

Comment 13

[Jim Mathies [:jimm]]

(In reply to :Gijs (he/him) from comment #12)

(In reply to :Nika Layzell from comment #11)

That is super weird... I'm a bit surprised that the scrollbars & resize
handle are actually appearing in the inspector TBH...

There's a hidden pref to always show anonymous content which is presumably
turned on in this profile.

When performing SessionRestore we do lie about the URI in a way which I
believe would affect the |.documentUri|

<snip analysis that'd just end up with broken links; see comment #11; >

I don't see an obvious way this could end up such that the tab is not
restored, but there's probably some way to make it happen here.

It'd probably be good to know what the browser.sessionstore.** prefs are set
to, and what has ended up logged in the browser console toolbox.

Jim, can you check your session restore prefs?

All of my sessionstore prefs are default except browser.sessionstore.upgradeBackup.latestBuildID.

Comment 14

[Mike de Boer [:mikedeboer]]

No, but I think my lack of reply already made that quite clear. :-/

The reason I circle back now, is because this seems to be easy to reproduce now when you look at bug 1535674! So Jason is trying to land a really neat optimization to await, but this bug is blocking him.

Both mconley and he were involved trying to debug where the problem/ race condition might be.

We narrowed it down to history.reloadCurrentEntry(); - https://searchfox.org/mozilla-central/rev/49e78df13e7a505827a3a86daae9efdf827133c6/browser/components/sessionstore/ContentRestore.jsm#230 - not doing anything.
The ProgressListener is not getting any messages, so it never fires the appropriate callback.
Last thing I know was that mconley recommended to Jason to run rr and set a breakpoint in nsSHistory::ReloadCurrentEntry(), but that's all.

For posterity, I'll n-i Jason, mconley and Nika here, because I think this is important to get resolved asap.

Comment 16

[Mike de Boer [:mikedeboer]]

Since it's really easy to reproduce - because Jason's changes to async make it 100% reproducable - I'm setting the priority and severity accordingly. This is causing broken sessions, infinite spinners and data-loss.

I hope we'll be able to resolve this very soon.

Comment 17

[Jason Orendorff [:jorendorff]]

See recent activity in bug 1535674.

jimm, is this fixed?

Comment 18

[:Gijs (he/him)]

Is the fix from bug 1535674 specific to pinned tabs? I'm wondering if bug 1421796 is the same type of issue, and based on comment #14, if there is a more fundamental DOM/docshell + frontend interaction that needs fixing.

Comment 19

[Jim Mathies [:jimm]]

(In reply to Jason Orendorff [:jorendorff] from comment #17)

See recent activity in bug 1535674.

jimm, is this fixed?

Haven't seen this in about a week or so.

Comment 20

[Mike de Boer [:mikedeboer]]

Yeah, I think no further investigation is necessary here.

Comment 22

[Sören Hentzschel]

(In reply to Jim Mathies [:jimm] from comment #19)

(In reply to Jason Orendorff [:jorendorff] from comment #17)

See recent activity in bug 1535674.

jimm, is this fixed?

Haven't seen this in about a week or so.

I still see this after every Firefox Nightly update.

Comment 23

[:Gijs (he/him)]

(In reply to Sören Hentzschel from comment #22)

(In reply to Jim Mathies [:jimm] from comment #19)

(In reply to Jason Orendorff [:jorendorff] from comment #17)

See recent activity in bug 1535674.

jimm, is this fixed?

Haven't seen this in about a week or so.

I still see this after every Firefox Nightly update.

Please file a separate bug with more details.

Comment 24

[Jim Mathies [:jimm]]

(In reply to :Gijs (he/him) from comment #23)

(In reply to Sören Hentzschel from comment #22)

(In reply to Jim Mathies [:jimm] from comment #19)

(In reply to Jason Orendorff [:jorendorff] from comment #17)

See recent activity in bug 1535674.

jimm, is this fixed?

Haven't seen this in about a week or so.

I still see this after every Firefox Nightly update.

Please file a separate bug with more details.

Picked this up again twice in that few days. :( Will post in bug 1548508.