Pinned tabs failing to restore in latest Firefox Nightly

VERIFIED FIXED in Firefox 67



4 months ago
2 months ago


(Reporter: dholbert, Assigned: jorendorff)



Dependency tree / graph

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox65 unaffected, firefox66 unaffected, firefox67blocking fixed)



(2 attachments)



4 months ago

We've had several reports of pinned tabs failing to be restored by session restore in today's Firefox Nightly.

For me, this happened twice, with different sets of pinned tabs failing to restore:
(1) After restarting Firefox to install an update, gmail + gcal tabs for MoCo account (but personal gmail + gcal were fine)

(2) After restarting Firefox just for the heck of it (no update), gcal tab for MoCo account & my MoCo slack tab failed to restore.

The failed-to-restore tabs just have the gray "oscillating ball" loading animation, and they stay in that state forever.

The only workaround I've found so far is to close the tab (e.g. middle-click the tab title) and then do undo-close-tab with Ctrl+Shift+T.

(Note: I performed this workaround between instances (1) & (2) above -- so the tabs that failed to restore in (2) were "newly" failing to restore. It's not that they were in a still-broken-from-before state when I got to instance (2) of the issue.)


Comment 1

4 months ago

I saved a snapshot of my browser profile which reliably reproduces the issue, and I was able to use mozregression to isolate a regression range:

--> regression from bug 1495072 ("Implement new, faster proposed await semantics").

Blocks: 1495072


4 months ago
Flags: needinfo?(jorendorff)

Comment 4

4 months ago

I've attached two screencasts showing the behavior difference.
"good" behavior screencast:

  • my first, second and final tab start out with gray throbber, but throbber changes to blue and the tab fully loads.
  • Subsequent pinned tabs get progressively loaded without me having to do anything - you can see their placeholder favicons change to throbbers and then back to the favicon as they load.

"bad" behavior screencast:

  • my first, second, and final tab start out with gray throbber, and never get past it.
  • Subsequent pinned tabs do not progressively load. They load lazily if I click them, but otherwise they just sit their with their favicon loaded as a lazy placeholder.

Comment 5

4 months ago

I tried in a fresh profile (with 9 pinned tabs of major sites) and was not able to reproduce the "subsequent pinned tabs do not progressively load" behavior.

So far I've only seen this with my regular browsing profile (and I've got a saved archive of my profile which reliably triggers the issue).


Comment 6

4 months ago

Interestingly, it does not reproduce (so far) for me if I start Firefox with the -safe-mode command-line argument. That may suggest that one of my extensions is partially at fault here.

Also: the "subsequent tabs do not progressively load" issue in comment 4 (shown in "bad" screencast) seems to be simply because we cap the number of pinned tabs that we load at once (to ~2), and in a profile where 2 tabs are busted, we never eagerly get past them. I just retriggered this with only 1 busted throbber-forever tab, and in that profile, the rest of the pinned tabs all eagerly loaded just fine.


Comment 7

4 months ago

FWIW, the issue seems to go away if I disable uBlock origin (like, disable the extension entirely, via about:addons).

So that extension may be involved somehow.


Comment 8

4 months ago

Actually maybe this is a more general addon issue (perhaps related to maybe some Firefox startup code that calls out to such addons?)


  • I see the issue when I disable all extensions except for uBlock origin.
  • I also see the issue when I disable all extensions except for "Facebook Container".
    ...but the issue goes away if I disable that last addon as well (whichever one it is).

Also, :zombie mentioned in IRC that they're seeing this issue too, and the issue went away when they disabled the Privacy Badger addon.


Comment 9

4 months ago

(Requesting tracking since this feels like a pretty big regression which we should aim to fix before shipping 67beta)

Keywords: regression

Thankfully we shipped DevEd 67.0b1 off a rev prior to bug 1495072 landing. I agree that we shouldn't ship b2 until this is resolved one way or another.

Bug 1495072 was backed out. If all goes well, Nightlies with build ID 20190313 or newer will be fixed.


Comment 12

4 months ago

I restarted a few times and it reproduced for me (in a few tabs) until I disabled NoScript.

<John-Galt> jorendorff: Well, if I had to guess...
<John-Galt> jorendorff:
<John-Galt> If it's hitting things like uBlock, the CSS bits would be my first guess
<zombie> but also Facebook Container, which i doubt has any content scripts :(
<John-Galt> No idea

Facebook Container is a background script, I guess?

I'll reland bug 1495072 behind a pref.

The bug is no longer reproducing for me and Ryan confirmed yesterday that it also works for him now, marking fixed.

Closed: 3 months ago
Resolution: --- → FIXED
Severity: normal → major
Assignee: nobody → jorendorff
Target Milestone: --- → mozilla67

Comment 14

3 months ago

(In reply to Pascal Chevrel:pascalc from comment #13)

The bug is no longer reproducing for me and Ryan confirmed yesterday that it also works for him now, marking fixed.

Right, the regressing change was backed out.

Flags: needinfo?(jorendorff)

Comment 15

3 months ago

Bug 1535674 is the followup to debug this so I can reland.

QA Whiteboard: [qa-triaged]
Flags: qe-verify+

Managed to reproduce the issue as well with Firefox 67.0a1(20190312095443); as per comment 7 with uBlock origin it did cause the loading issues.
Can confirm that with 68.0a1 (2019-05-02) - Windows10, Ubuntu 16.06, macOS 10.14.3 the issue did not reproduce at all.

QA Whiteboard: [qa-triaged]
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.