Tabs are all restored as blank frequently

ASSIGNED
Assigned to

Status

()

Firefox
Session Restore
P2
major
ASSIGNED
6 months ago
2 months ago

People

(Reporter: Realestate21, Assigned: dao)

Tracking

(Depends on: 1 bug, 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 wontfix)

Details

Attachments

(8 attachments)

(Reporter)

Description

6 months 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

6 months ago
+1
Tabs are all restored as blank frequently after restart. Firefox 55

Comment 2

6 months 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

6 months 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

6 months ago
philipp reports being able to reproduce this with about:newtab as the homepage as well.

Comment 5

6 months ago
[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

Updated

6 months ago
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

6 months ago
Severity: normal → major
(Assignee)

Comment 7

6 months 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

6 months ago
Flags: needinfo?(dao+bmo) → needinfo?(madperson)
(Assignee)

Comment 8

6 months ago
Can't reproduce in 56 either. This is on Ubuntu. Will try 55 next.

Comment 9

6 months ago
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

6 months 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

6 months 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

6 months 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

6 months 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

6 months 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

6 months ago
Duplicate of this bug: 1387747
Duplicate of this bug: 1387366
See Also: → bug 1365713
(Assignee)

Comment 16

6 months 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

6 months 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

6 months 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.
(Reporter)

Comment 22

6 months 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

6 months 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+

Comment 24

6 months ago
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

6 months ago
See Also: → bug 1388784

Updated

6 months ago
See Also: → bug 1388297
(Assignee)

Updated

6 months ago
See Also: bug 1388784
Duplicate of this bug: 1388784

Updated

6 months 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

6 months ago
Bug 1373902 may be a duplicate ?
(Assignee)

Updated

6 months ago
Duplicate of this bug: 1373902

Comment 29

6 months 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

6 months 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

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

Comment 32

6 months 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

6 months 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

6 months ago
Depends on: 1054740
(Assignee)

Comment 37

5 months 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

5 months 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 43

5 months 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

5 months 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

5 months 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

5 months 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

5 months ago
I'm on OS X.

Comment 48

5 months ago
maybe related to bug 1366477?
32bit win10

Comment 49

5 months 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

5 months 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

5 months 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

5 months 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

5 months 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
(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

5 months 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
(Assignee)

Comment 60

5 months ago
With bug 1054740 fixed, can somebody still reproduce this in the latest Nightly?

Comment 61

5 months ago
(In reply to Dão Gottwald [::dao] from comment #60)
> With bug 1054740 fixed, can somebody still reproduce this in the latest
> Nightly?

working fine now in x86 linux build 20170827

Comment 62

5 months ago
Upgraded to 55.0.3 (x64) windows and observed this issue. I lost many tabs I was working with. Is this expected to be fixed in 55.0.3 or some later version?

Comment 63

5 months ago
On 55.0.3 All tabs but the first and active tab are blank after restart for me. Happens reliably.

Comment 64

5 months ago
Created attachment 8902134 [details]
2017-08-29 08:01 about:support raw.txt

Not, or not yet, reproducible here with 55.0.3. And I don't recall finding the bug with 55.0.2. 

My most recent restoration: 

* multiprocess enabled
* 625 tabs with around 73 groups across 12 windows. 

----

$ pkg info firefox | grep -i version
Version        : 55.0.3_1,1
$ date ; uname -a
Tue 29 Aug 2017 08:05:41 BST
FreeBSD momh167-gjp4-hpelitebook8570p-freebsd 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320869: Mon Jul 10 13:57:55 UTC 2017     root@releng3.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
$ 

----

If it helps to refine the bug in the cases of other users of 55.0.3: 

* when simply starting Firefox – **never** allowing a _restart_ with so many tabs – I allow time for all elements (of add-ons etc.) to appear, in the single window, before beginning restoration. 

I use Session Manager to load the session, and I typically replace (without appending).
(Assignee)

Updated

5 months ago
Depends on: 1394765
(Assignee)

Updated

5 months ago
Depends on: 1394767

Comment 65

5 months ago
Just had the auto upgrade to 55.0.3 run on a second computer. Tabs lost due to this bug (again). Since this is so easily reproducible, how can we help identify the source of this bug?
(Assignee)

Comment 66

5 months ago
(In reply to nbinont from comment #65)
> Just had the auto upgrade to 55.0.3 run on a second computer. Tabs lost due
> to this bug (again). Since this is so easily reproducible, how can we help
> identify the source of this bug?

This / comment 62 is the first time we hear that this is a problem in 55.0.3. I think you might be seeing a different bug.

Comment 67

5 months ago
Possibly, though the symptoms are essentially the same. I first noticed this with the upgrade to 55.0.1. It has been present in 55.0.1, 55.0.2, and recently 55.0.3. Graham (comment 64) is also seeing it.
(Assignee)

Comment 68

5 months ago
(In reply to nbinont from comment #67)
> Possibly, though the symptoms are essentially the same. I first noticed this
> with the upgrade to 55.0.1. It has been present in 55.0.1, 55.0.2, and
> recently 55.0.3.

Are you using any add-ons that could be interfering here? Are there any errors in the browser console?

> Graham (comment 64) is also seeing it.

I don't think so. He wrote: "Not, or not yet, reproducible here with 55.0.3"

Comment 69

5 months ago
Found my issue. Disabling the IE-Tab add-on ( https://addons.mozilla.org/en-US/firefox/addon/ie-tab/ ) resolved the problem. Thanks for helping to debug. Would have been nice if the addon was simply disabled on upgrade instead of having the tabs lost. Addons.mozilla.org knows the addon wasn't compatible.

Comment 70

5 months ago
I'm still on 55.0.2. Tried restarting in safe mode, but the blank tabs are still there. Should I upgrade to 55.0.3 or will I risk losing more tabs?

(OS X 10.11.6, multiprocess enabled)

Comment 71

5 months ago
However, in safe mode, when I click on some of the blank tabs, I am able to see the URL in the location bar. I tried this with Add-ons enabled for some other blank tabs and the location bar remained completely blank.

This error in the browser console looked like it could be related:

TypeError: tab is undefined at moz-extension://2d0dd6f4-9023-b346-8709-2fc8f01c9db1/background.js:633  zotero.js:199:4
	Zotero</this.logError moz-extension://2d0dd6f4-9023-b346-8709-2fc8f01c9db1/zotero.js:199:4
	Zotero.Utilities.logCallbackError/< moz-extension://2d0dd6f4-9023-b346-8709-2fc8f01c9db1/utilities.js:57:4

This is for Zotero Connector 5.0.18, which is a WebExtension.

Comment 72

5 months ago
About sessionstore <https://addons.mozilla.org/firefox/addon/about-sessionstore/> might help to refine symptoms in cases where only _some_ (not all) about:newtab 'New Tab' tabs occur. 

With the extension installed: before the next _restart_ of Firefox, visit about:sessionstore and (Control-F) find 'New Tab'; note the number of matches. 

At the time of writing I have 627 tabs, 86 of which are loaded, not one 'New Tab'. I'll use Session Manager to save the session, then switch locale to require a restart, then tell whether the issue is reproducible with my set of extensions.

Comment 73

5 months ago
> … switch locale to require a restart …

As things turned out: I used Session Manager to 'Save and restore at startup', which is probably comparable to a restart for the purposes of this bug. 

A number of issues are remarkable (worst: excruciating slowness if restoration begins too soon, without pausing to allow just one _entirely extended_ window to load), however: 

* I should treat all of those issues as beyond the scope of this bug

– catch me in IRC if you'd like to discuss any spin-off. I should have plenty of free time today. 

Essentially, for 1388628: 

* the restored session comprises 627 tabs, none of which are 'New Tab'

– success. 

----

Side note: tabs counted with 
           Tab Tally (Paul Morris) 
           <https://addons.mozilla.org/firefox/addon/tab-tally/>.

Comment 74

5 months ago
Sincere thanks nbinont,

Similar to their experience an upgrade from 54.0.1 to 55.0.3 (on win7) caused this 100% reproducible for me on two machines: on close and restart only the focus and first tabs load, with all others set to about:newtab.

Behaviour follows the enable status of 'IE Tab'; that's now binned and it's very nice to have my tabs back from via a previous.js

Comment 75

5 months ago
Started to get this problem after updating to 56b7. 
I disabled all add-ons, and it got fixed. 
Then when I went to try bisecting which one could be at fault... Even re-enabling everything as it previously was didn't seem to manifest the issue anymore :/

In other days some days ago I noticed the following in the console (doesn't happen anymore). Not sure how much it could be related
> Failed to load module resource:///modules/sessionstore/SessionStorage.jsm.  XPCOMUtils.jsm:315
>NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIXPCComponents_Utils.import]  XPCOMUtils.jsm:309
> TelemetryStopwatch: key "FX_SESSION_RESTORE_CONTENT_COLLECT_DATA_MS" was already initialized  TelemetryStopwatch.jsm:343
> ReferenceError: SessionStorage is not defined content-sessionStore.js:602:7
(Assignee)

Updated

5 months ago
Depends on: 1397365

Comment 76

3 months ago
I don't know if this is right place to post this information.
I have FF 56.0 x64 on GNU/Linux Debian 9 'stretch' exhibiting seeming same behaviour, but looses tabs partially.

When I close FF it saves opened tabs as expected, but when I start FF and click on some saved tabs to right-end (with icons and page titles) they become "about:blank" tabs without any history to go back. Look at screenshots to see how it looks now.

It looks like "sessionstore.jsonlz4" file corruption to me. I have backed up recovery.jsonlz4 and sessionstore.jsonlz4 and can upload them for a review if it will help to reproduce and debug this issue. 

Original thread was posted here: https://support.mozilla.org/en-US/questions/1180398

Comment 77

3 months ago
Created attachment 8919873 [details]
screenshot 1 of 3 saved session corruption

This is what just opened saved session looks like.

Comment 78

3 months ago
Created attachment 8919874 [details]
screenshot 2 of 3 saved session corruption

This is what happens if I click on affected tabs to bring them to focus.

Comment 79

3 months ago
Created attachment 8919875 [details]
screenshot 3 of 3 saved session corruption

This is how it looks like after I close Firefox and start it again.

Comment 80

3 months ago
(In reply to sizeofbool from comment #76)
> I don't know if this is right place to post this information.
> I have FF 56.0 x64 on GNU/Linux Debian 9 'stretch' exhibiting seeming same
> behaviour, but looses tabs partially.
> 
> When I close FF it saves opened tabs as expected, but when I start FF and
> click on some saved tabs to right-end (with icons and page titles) they
> become "about:blank" tabs without any history to go back. Look at
> screenshots to see how it looks now.
> 
> It looks like "sessionstore.jsonlz4" file corruption to me. I have backed up
> recovery.jsonlz4 and sessionstore.jsonlz4 and can upload them for a review
> if it will help to reproduce and debug this issue. 
> 
> Original thread was posted here:
> https://support.mozilla.org/en-US/questions/1180398

I believe I experience something similar that was related to an addon that unloaded tabs.
Do you have any such addon. Perhaps one that manages tabs in some way?
Once I remove the addon the issue did not reoccur.

Comment 81

3 months ago
Created attachment 8919879 [details]
sessionstore.jsonlz4 and previous.jsonlz4 session files

Comment 82

3 months ago
(In reply to Caspy7 from comment #80)
> Do you have any such addon. Perhaps one that manages tabs in some way?
> Once I remove the addon the issue did not reoccur.

All addons are disabled for a long time with the exception of AdBlock Plus and I didn't used them for a while.
I keep them installed just to use from time to time, but keep them in disabled state after that.
You can see what addons are installed and other info about my system and browser in my post on support.mozilla.org forum.
Priority: -- → P2

Updated

2 months ago
status-firefox57: affected → wontfix
You need to log in before you can comment on or make changes to this bug.