Tabs are all restored as blank frequently

ASSIGNED
Assigned to

Status

()

Firefox
Session Restore
--
major
ASSIGNED
14 days ago
6 days ago

People

(Reporter: Realestate21, Assigned: dao)

Tracking

(Depends on: 2 bugs, Blocks: 1 bug, {regression})

55 Branch
regression
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify +

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox55blocking verified, firefox56 fixed, firefox57 affected)

Details

Attachments

(3 attachments)

(Reporter)

Description

14 days ago
Created attachment 8895228 [details]
firefox_v55_09082017.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36

Steps to reproduce:

The bug is repeated accidentally, but often.


Actual results:

Tabs are all restored as blank frequently after restart.

Comment 1

14 days ago
+1
Tabs are all restored as blank frequently after restart. Firefox 55

Comment 2

14 days ago
Also have this issue, also after creating a new profile. Also suffering from bug 1386322, may be related. Nightly 2017-08-08 (57.0a1).

Comment 3

14 days ago
After some experimentation, on a non-synced profile and two synced (different account) profiles, I've traced it to (in my case):
- homepage set to "file://..."
- startup set to restore windows and tabs

Returning the homepage to a "http(s)://" link makes everything work fine.

Comment 4

14 days ago
philipp reports being able to reproduce this with about:newtab as the homepage as well.
[Tracking Requested - why for this release]:
new regression on firefox 55 which will lead to loss of sessiondata for some users.

i have those str in a new profile:
- go to about:preferences
- change the start options to "show windows and tabs from last session" and the homepage to "about:newtab"
- close the browser
- reopen firefox twice
- then you get about:newtab and only blank tabs restored

since the steps involve closing and reopening the browser a few times i have a hard time narrowing it down with mozregression.
however it appears that the bug was first introduced on the beta channel in 55.0b5: https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=FIREFOX_55_0b4_RELEASE&tochange=FIREFOX_55_0b5_RELEASE
in that range bug 1365541 would stick out as related to session restore.
status-firefox55: --- → affected
status-firefox56: --- → affected
status-firefox57: --- → affected
status-firefox-esr52: --- → unaffected
tracking-firefox55: --- → ?
Flags: needinfo?(dao+bmo)
Keywords: regression
Status: UNCONFIRMED → NEW
Component: Untriaged → Session Restore
Ever confirmed: true
Also needinfo Mike as this is pretty important and we need a fix asap.
tracking-firefox55: ? → blocking
Flags: needinfo?(mdeboer)

Updated

14 days ago
Severity: normal → major
(Assignee)

Comment 7

14 days ago
(In reply to [:philipp] from comment #5)
> [Tracking Requested - why for this release]:
> new regression on firefox 55 which will lead to loss of sessiondata for some
> users.
> 
> i have those str in a new profile:
> - go to about:preferences
> - change the start options to "show windows and tabs from last session" and
> the homepage to "about:newtab"
> - close the browser
> - reopen firefox twice
> - then you get about:newtab and only blank tabs restored

Can you reproduce with these steps in nightly? I can't.
(Assignee)

Updated

14 days ago
Flags: needinfo?(dao+bmo) → needinfo?(madperson)
(Assignee)

Comment 8

14 days ago
Can't reproduce in 56 either. This is on Ubuntu. Will try 55 next.
i can't reproduce it on nightly with "about:newtab" but it's still buggy with a "file:/..." uri set as homepage
Flags: needinfo?(madperson)
(Assignee)

Comment 10

14 days ago
Okay, I can reproduce with a file:// homepage in nightly.

This seems relevant:

A coding exception was thrown in a Promise resolution callback.
See https://developer.mozilla.org/Mozilla/JavaScript_code_modules/Promise.jsm/Promise

Full message: TypeError: access to strict mode caller function is censored
Full stack: NS_ASSERT@resource://gre/modules/debug.js:50:7
restoreTab@resource:///modules/sessionstore/SessionStore.jsm:3552:5
restoreTabs@resource:///modules/sessionstore/SessionStore.jsm:3539:7
ssi_restoreWindow@resource:///modules/sessionstore/SessionStore.jsm:3404:7
ssi_restoreWindows@resource:///modules/sessionstore/SessionStore.jsm:3484:5
initializeWindow@resource:///modules/sessionstore/SessionStore.jsm:1158:11
onBeforeBrowserWindowShown/<@resource:///modules/sessionstore/SessionStore.jsm:1307:9
process@resource://gre/modules/Promise-backend.js:922:23
walkerLoop@resource://gre/modules/Promise-backend.js:806:7
scheduleWalkerLoop/<@resource://gre/modules/Promise-backend.js:742:11
(Reporter)

Updated

14 days ago
Summary: Tabs are all restored as blank frequently after restart of applying Firefox 55 update. → Tabs are all restored as blank frequently after restart of applying Firefox 55 update. Windows 10 (x64)
(Assignee)

Comment 11

14 days ago
(In reply to Dão Gottwald [::dao] from comment #10)
> Okay, I can reproduce with a file:// homepage in nightly.

I meant 55. I couldn't reproduce this with about:blank as the homepage in 55.
(Assignee)

Comment 12

14 days ago
(In reply to Dão Gottwald [::dao] from comment #10)
> Okay, I can reproduce with a file:// homepage in nightly.
> 
> This seems relevant:
> 
> A coding exception was thrown in a Promise resolution callback.
> See
> https://developer.mozilla.org/Mozilla/JavaScript_code_modules/Promise.jsm/
> Promise
> 
> Full message: TypeError: access to strict mode caller function is censored
> Full stack: NS_ASSERT@resource://gre/modules/debug.js:50:7
> restoreTab@resource:///modules/sessionstore/SessionStore.jsm:3552:5

That's:

  restoreTab(tab, tabData, options = {}) {
    NS_ASSERT(!tab.linkedBrowser.__SS_restoreState,
              "must reset tab before calling restoreTab()");
(Reporter)

Comment 13

14 days ago
Most often it reproduce after visiting the Add-on Manager > Extensions. 
Tested on two different PC on which is installed  Windows 10 (x64)

Updated

14 days ago
Duplicate of this bug: 1387747
Duplicate of this bug: 1387366
See Also: → bug 1365713
(Assignee)

Comment 16

14 days ago
I need to investigate further what exactly is going on, but the most straightforward option would likely be to back out bug 1365541 from 55. This wouldn't be a regression compared to 54.
Created attachment 8895378 [details] [diff] [review]
Bug-1388628.diff

Approval Request Comment
[Feature/Bug causing the regression]: bug 1365541
[User impact if declined]: Tabs fail to restore 
[Is this code covered by automated tests?]: Some parts are not https://codecov.io/gh/marco-c/gecko-dev/src/master/browser/components/sessionstore/SessionStore.jsm#L3358
[Has the fix been verified in Nightly?]: not yet
[Needs manual test from QE? If yes, steps to reproduce]:  Yes, see comment #5 for the STR
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: it is a backout of a change that we did a month ago and the patch applies cleanly. I guess it isn't that risky
[Why is the change risky/not risky?]: 
[String changes made/needed]:
Attachment #8895378 - Flags: review?(dao+bmo)
Attachment #8895378 - Flags: approval-mozilla-release?

Comment 18

14 days ago
uplift
To have time to have the CI running to start the builds, I landed it:
https://hg.mozilla.org/releases/mozilla-release/rev/cace0357d40e875ea45b9ccad99f8785fc2cdb50
as I was implementing your suggestion in comment #16
Blocks: 1365541
status-firefox55: affected → fixed
(Assignee)

Comment 19

14 days ago
I'm currently failing to reproduce this again _without_ the backout, so I can't verify that the backout helps...

If somebody can consistently reproduce this on Linux, here's a Linux64 build with the backout (directly from sylvestre's push):
https://queue.taskcluster.net/v1/task/ZYpjJyn6SRuJDu8tHixYww/runs/0/artifacts/public/build/target.tar.bz2

Mac and Windows builds don't seem to be ready yet.
(Assignee)

Comment 20

14 days ago
Windows 2012 pgo build:
https://queue.taskcluster.net/v1/task/W6nndR7xTweyqCYMvBI-lA/runs/0/artifacts/public/build/target.zip
(Assignee)

Comment 21

14 days ago
Mac opt:
https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-release-macosx64/1502290970/firefox-55.0.1.en-US.mac.dmg
(Reporter)

Comment 22

13 days ago
(In reply to Dão Gottwald [::dao] from comment #20)
> Windows 2012 pgo build:
> https://queue.taskcluster.net/v1/task/W6nndR7xTweyqCYMvBI-lA/runs/0/
> artifacts/public/build/target.zip

Cool! It looks like it's working to me. Now the session is always restored! Thank you! )
(Assignee)

Comment 23

13 days ago
Comment on attachment 8895378 [details] [diff] [review]
Bug-1388628.diff

(In reply to Realestate21 from comment #22)
> (In reply to Dão Gottwald [::dao] from comment #20)
> > Windows 2012 pgo build:
> > https://queue.taskcluster.net/v1/task/W6nndR7xTweyqCYMvBI-lA/runs/0/
> > artifacts/public/build/target.zip
> 
> Cool! It looks like it's working to me. Now the session is always restored!
> Thank you! )

Thanks for checking!
Attachment #8895378 - Flags: review?(dao+bmo) → review+
i can confirm too that i'm no longer able reproduce the problem with the build from https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-release-win64/1502290826/ - either with about:newtab or a file://-link set as a homepage.

Updated

13 days ago
See Also: → bug 1388784

Updated

13 days ago
See Also: → bug 1388297
(Assignee)

Updated

13 days ago
See Also: bug 1388784
Duplicate of this bug: 1388784

Updated

13 days ago
See Also: bug 1388297
Flags: qe-verify+
Comment on attachment 8895378 [details] [diff] [review]
Bug-1388628.diff

I landed it in m-r
Flags: needinfo?(mdeboer)
Attachment #8895378 - Flags: approval-mozilla-release? → approval-mozilla-release+

Comment 27

13 days ago
Bug 1373902 may be a duplicate ?
(Assignee)

Updated

13 days ago
Duplicate of this bug: 1373902

Comment 29

13 days ago
I have reproduced this issue using Firefox  55.0-build1 on Win 10 x64.
I can confirm this issue is fixed, I verified using Firefox 55.0.1-build2 on Win 10 x64.
status-firefox55: fixed → verified

Comment 30

12 days ago
Firefox 55.0.1 has dramatically worsened this behavior for me. Firefox now only restores the last tab I was looking at; all others are loaded as about:blank (while still being stored properly in sessionstore.js). On next restore, all blank tabs are deleted.

Comment 31

12 days ago
...however a Refresh managed to fix it. Not sure what the base issue was.

Comment 32

12 days ago
Similar to what Aleksei reported, I can restore tabs that were loaded before I upgraded to 55.0.1, but many older ones still cannot be restored. I have 183 tabs open. Many of the older tabs appear with a site icon but no title; I suspect the non-restorable ones are the ones missing titles. The oldest tabs (20 of them, leftmost on the tab strip) still show the title and can be restored.
ok, thanks for your comments. Please let us know if you still see the issue or it was just caused by the upgrade to 55.0.1
(Assignee)

Comment 34

12 days ago
Created attachment 8896129 [details] [diff] [review]
patch for beta uplift: disable reusing the selected tab

While I investigate a proper fix for central, we should probably just disable this on beta too.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=bc4eccf28088b741ac1e7b4e55c0fbc62b0d387e
Assignee: nobody → dao+bmo
Status: NEW → ASSIGNED
Attachment #8896129 - Flags: review?(mdeboer)
Comment on attachment 8896129 [details] [diff] [review]
patch for beta uplift: disable reusing the selected tab

Review of attachment 8896129 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/components/sessionstore/SessionStore.jsm
@@ +3288,5 @@
>        let userContextId = tabData.userContextId;
>        let select = t == selectTab - 1;
>        let tab;
>  
> +      /* Disabled because of bug 1388628:

Well, I'm quite happy that your change made this easy so easy to disable, but are we OK with shipping dead code? I think adding:
```js
// TODO: re-using the selected tab has been disabled due to bug 1388628.
```
might be a better way?
Attachment #8896129 - Flags: review?(mdeboer) → review+
In a context of a dot release, I am fine with dead code.
Do we agree that it is a driver for a 55.0.2 dot release?
(Assignee)

Updated

12 days ago
Depends on: 1054740
(Assignee)

Comment 37

12 days ago
(In reply to Mike de Boer [:mikedeboer] from comment #35)
> Well, I'm quite happy that your change made this easy so easy to disable,
> but are we OK with shipping dead code? I think adding:
> ```js
> // TODO: re-using the selected tab has been disabled due to bug 1388628.
> ```
> might be a better way?

I don't think it matters. I can just remove these lines if you prefer.

(In reply to Sylvestre Ledru [:sylvestre] from comment #36)
> In a context of a dot release, I am fine with dead code.
> Do we agree that it is a driver for a 55.0.2 dot release?

My patch is intended for beta. As I understand it, no further patches are needed on release, right?
Flags: needinfo?(sledru)
Flags: needinfo?(mdeboer)
yeah, I confused this bug with bug 1388584. sorry :/
Flags: needinfo?(sledru)
(In reply to Dão Gottwald [::dao] from comment #37)
> I don't think it matters. I can just remove these lines if you prefer.

Indeed, I leave it up to you! :)
Flags: needinfo?(mdeboer)
(Assignee)

Comment 40

12 days ago
Comment on attachment 8896129 [details] [diff] [review]
patch for beta uplift: disable reusing the selected tab

Approval Request Comment

see comment 17
Attachment #8896129 - Flags: approval-mozilla-beta?
Comment on attachment 8896129 [details] [diff] [review]
patch for beta uplift: disable reusing the selected tab

We took it for the release, let's take it for the beta too
Attachment #8896129 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
(Assignee)

Comment 42

12 days ago
uplift
https://hg.mozilla.org/releases/mozilla-beta/rev/f7e05dffb1ab4e0b9ed46fa2350c3b5fd4b9efe4
status-firefox56: affected → fixed
(Assignee)

Comment 43

12 days ago
I think bug 1351358 may also play a role here, attachment 8864117 [details] [diff] [review] in particular, as it updates the initial browser's remoteness based on the homepage URL even if we'll restore the session instead of loading that URL... This is quite bogus, but without bug 1365541 (and bug 1351677 before that), it didn't matter as far as session restore was concerned because it wouldn't have used that tab.
Blocks: 1351358

Comment 44

11 days ago
Win 7 x64, FF x64, restoring a session with pinned tabs, one of them (about:addons) focused.
FF 55: OK when using FF's built-in session manager, broken when using https://addons.mozilla.org/en-US/firefox/addon/session-manager/ (the number of tabs & pinned tabs is correct, but the focused one steals the URL from the rightmost pinned one + all the rest go about:blank).
FF 55.0.1: always OK.

Comment 45

11 days ago
Does it happen only on Windows x64 as the title says, or was it reproduced on other platforms ?
Where are the OS/platform/hardware fields of Bugzilla that are usually shown? I don't see them.

Comment 46

11 days ago
(In reply to nivtwig from comment #45)
> Does it happen only on Windows x64 as the title says, or was it reproduced
> on other platforms ?
> Where are the OS/platform/hardware fields of Bugzilla that are usually
> shown? I don't see them.

Me using Debian's package on amd64 is affected.
OS: Unspecified → All
Hardware: Unspecified → All
Summary: Tabs are all restored as blank frequently after restart of applying Firefox 55 update. Windows 10 (x64) → Tabs are all restored as blank frequently after restart of applying Firefox 55 update

Comment 47

11 days ago
I'm on OS X.

Comment 48

10 days ago
maybe related to bug 1366477?
32bit win10

Comment 49

10 days ago
Found a Reliable STR

and if seems to be a cobo of different bugs

session restore compression,lazylabs,homepage loading method which all were fixed in FF55

See https://bugzilla.mozilla.org/show_bug.cgi?id=1366477#c17

Comment 50

10 days ago
Can you guys fix this asap as this is in stable and sessions are being lost my many users.

is 55.0.2 going to fix this?

can reproduce this in 55.0.1 stable
and loosing all my sessions.
Flags: needinfo?(dao+bmo)

Comment 51

10 days ago
Can you guys fix this asap as this is in stable and sessions are being lost my many users.

is 55.0.2 going to fix this?


Is it also fixed in Nightly 57?

can reproduce this in 55.0.1 stable
and loosing all my sessions.
55.0.2 should fix it. We will ship it Monday or Tuesday
Flags: needinfo?(dao+bmo)

Comment 53

10 days ago
(In reply to Sylvestre Ledru [:sylvestre] from comment #52)
> 55.0.2 should fix it. We will ship it Monday or Tuesday

Thanks for the info.


What about Beta and Nightly57?
Same date?
56.0beta 3 should be live Tuesday
Nightly, don't know

Comment 55

9 days ago
Since this goes beyond just version 55, should that get taken out of the bug title? Thanks.
indeed!
Summary: Tabs are all restored as blank frequently after restart of applying Firefox 55 update → Tabs are all restored as blank frequently
Depends on: 1390228
Blocks: 1330633
See Also: → bug 629232
(In reply to Realestate21 from comment #0)
> Created attachment 8895228 [details]
> firefox_v55_09082017.png

I exactly see this behaviour after updating Firefox from 54.0.1 to 55.0.2 or 56.0b3 on a Mac.

I have two Firefox windows open (6 tabs and 22 tabs). Everything works as expected using Firefox 54.0.1. However, starting either of the newer Firefox versions, two windows open but the second window has 22 empty tabs (as seen in the screenshot). 

This also corrupts the stored session data, i.e. downgrading to the 54.0.1 version, the session cannot be restored. I have to copy the sessionstore-backups/previous.js file to sessionstore.js to recover the session.
(In reply to myself from comment #57)
> I exactly see this behaviour after updating Firefox from 54.0.1 to 55.0.2 or
> 56.0b3 on a Mac.

Found out that this issue was due to an outdated extension.

I checked add-on manager and 10 add-ons had updates available. I had add-on manager install these updates and now FF55 restores the session as expected.

Comment 59

6 days ago
(In reply to Daniel Kabs, reporting bugs since 2002 from comment #57)
> (In reply to Realestate21 from comment #0)
> > Created attachment 8895228 [details]
> > firefox_v55_09082017.png
> 
> I exactly see this behaviour after updating Firefox from 54.0.1 to 55.0.2 or
> 56.0b3 on a Mac.
> 
> I have two Firefox windows open (6 tabs and 22 tabs). Everything works as
> expected using Firefox 54.0.1. However, starting either of the newer Firefox
> versions, two windows open but the second window has 22 empty tabs (as seen
> in the screenshot). 
> 
> This also corrupts the stored session data, i.e. downgrading to the 54.0.1
> version, the session cannot be restored. I have to copy the
> sessionstore-backups/previous.js file to sessionstore.js to recover the
> session.

You cannot restore a session between 56 or above versions, and pre 56 versions because the session store file format was changed to a compressed format .lz4 . They didn't make the change backward or forward compatible. 

See Bug 1376983
You need to log in before you can comment on or make changes to this bug.