1090430 - [e10s] Restored foreground "about:preferences" tab just renders as a giant throbber image

Status: VERIFIED FIXED

(Core :: General, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: screenshot

STR:
 1. Visit about:preferences
 2. Tick "Enable e10s"
 3. Agree to restart.

EXPECTED RESULTS:
My about:preferences tab should be restored.

ACTUAL RESULTS:
After Firefox restarts (in e10s mode), your about:preferences tab is restored as a giant throbber icon. Can't fix it by reloading or changing tabs.

(If I open a different tab & visit about:preferences in *that* tab, then *that* tab is fine. Similarly, if I had a restored *background* tab at about:preferences, then that one is loaded fine. Just the foreground restored about:preferences tab is busted.)


ALTERNATE STR:
 0. Already have e10s enabled.
 1. Visit about:preferences.
 2. Quit Firefox (Ctrl+Q)
 3. Start Firefox.
 4. On the home page, click the "Restore previous session" button at bottom-right.


(This isn't 100% reproducible. I was able to reproduce in a fresh profile a minute ago, and now I can't reproduce in that profile or a new fresh profile. I'm guessing there's a race condition involved.)

Comment 1

[Daniel Holbert [:dholbert]]

Nightly 36.0a1 (2014-10-28)
Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0

Comment 3

[Daniel Holbert [:dholbert]]

FWIW, when I hit this, it appears that the about:preferences content is *really there*, but we're just not painting it.

e.g. if I click on the correct part of the page, I can open menus (and the menus do pop up, though the rest of the page remains unchanged -- it's still the throbber).

And if I click on the left side (where the "General"|"Content"|etc. side-tabs are), then I can see my URL bar update to e.g. "about:preferences#content" as I navigate between sections.

Comment 4

[:Felipe Gomes (needinfo for replies!)]

Thanks Daniel. That confirms the theory that we had on triage today that the pendingpaint tab styling [1] is improperly being applied to about:preferences, and never removed because it's not a remote tab and therefore never receives MozAfterRemotePaint.

[1] http://hg.mozilla.org/mozilla-central/annotate/c0ddb1b098ec/browser/base/content/tabbrowser.css#l78

Comment 5

[Jonathan Howard]

This isn't limited to about:preferences.
Any non-e10s restored foreground does same. e.g. about:newtab

Comment 7

[Jonathan Howard]

For reference Bug 1099857 was created and now fixed. Quite similar in nature but this is still broken.

I notice (this bug [or maybe will need a new one]) when restarting from nightly updates.

Comment 9

[Steven MacLeod [:smacleod]]

Discussed with Felipe, stealing.

Comment 10

[Steven MacLeod [:smacleod]]

Attachment: MozReview Request: bz://1090430/smacleod

Comment 11

[Steven MacLeod [:smacleod]]

/r/1067 - Bug 1090430 - Make sure a browser is still remote before showing the busy spinner. r=?

Pull down this commit:

hg pull review -r c0d0faa7d355d3f6a7f57f76d40db378ad5f356d

Comment 12

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

https://reviewboard.mozilla.org/r/1065/#review635

Just one nit, but otherwise I think this looks good!

::: browser/base/content/tabbrowser.xml
(Diff revision 1)
> +                if (toBrowser.getAttribute("remote") == "true") {

I'd suggest toBrowser.isRemoteBrowser instead of the direct attribute check - otherwise, this looks good to me.

Comment 13

[Steven MacLeod [:smacleod]]

https://reviewboard.mozilla.org/r/1065/#review637

> I'd suggest toBrowser.isRemoteBrowser instead of the direct attribute check - otherwise, this looks good to me.

The reason I went with the attribute check is that's how it's being done everywhere else in tabbrowser including a couple lines above in this method. There are no uses of isRemoteBrowser at all in here.

What are your thoughts on this?

Comment 14

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

I'd say it's probably because the work in tabbrowser was done before isRemoteBrowser came along. Over time, we should probably migrate the stuff in tabbrowser to use isRemoteBrowser as well. Feels cleaner than doing the manual attribute look-up.

Comment 16

[Steven MacLeod [:smacleod]]

https://hg.mozilla.org/integration/fx-team/rev/9c4e1b93df2c

Comment 17

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/9c4e1b93df2c

Comment 18

[Bogdan Maris, Desktop Test Engineering]

Reproduced the initial issue using an old Nightly (2014-11-05), verified that about:preferences and other about pages load after restart/quit using latest Nightly (2014-12-03) on Windows 7 64bit, Mac OS X 10.9.5 and Ubuntu 14.04 32bit.

Comment 20

[Steven MacLeod [:smacleod]]

Attachment: MozReview Request: Bug 1090430 - Make sure a browser is still remote before showing the busy spinner. r=?