Tabs are all restored as blank frequently

RESOLVED FIXED

Status

()

P2
major
RESOLVED FIXED
2 years ago
11 months ago

People

(Reporter: antoninamir21, Assigned: dao)

Tracking

(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

2 years ago
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

2 years ago
+1
Tabs are all restored as blank frequently after restart. Firefox 55

Comment 2

2 years 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

2 years 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

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

Comment 5

2 years 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

2 years 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

2 years ago
Severity: normal → major
(Assignee)

Comment 7

2 years 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

2 years ago
Flags: needinfo?(dao+bmo) → needinfo?(madperson)
(Assignee)

Comment 8

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

Comment 9

2 years 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

2 years 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

2 years 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

2 years 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

2 years 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

2 years 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

2 years ago
Duplicate of this bug: 1387747
Duplicate of this bug: 1387366
See Also: → bug 1365713
(Assignee)

Comment 16

2 years 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.
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?
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
status-firefox55: affected → fixed
(Assignee)

Comment 19

2 years 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

2 years 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

2 years 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

2 years 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

2 years ago
See Also: → bug 1388784

Updated

2 years ago
See Also: → bug 1388297
(Assignee)

Updated

2 years ago
See Also: bug 1388784
Duplicate of this bug: 1388784

Updated

2 years 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

2 years ago
Bug 1373902 may be a duplicate ?
(Assignee)

Updated

2 years ago
Duplicate of this bug: 1373902
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

2 years 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

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

Comment 32

2 years 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

2 years ago
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

2 years ago
Depends on: 1054740
(Assignee)

Comment 37

2 years 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

2 years 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

2 years 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

2 years 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

2 years 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

2 years 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

2 years ago
I'm on OS X.

Comment 48

2 years ago
maybe related to bug 1366477?
32bit win10

Comment 49

2 years 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

2 years 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

2 years 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

2 years 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

2 years 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

2 years 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

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

Comment 61

2 years 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

2 years 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

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

Comment 64

2 years ago
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

2 years ago
Depends on: 1394765
(Assignee)

Updated

2 years ago
Depends on: 1394767

Comment 65

2 years 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

2 years 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

2 years 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

2 years 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

2 years 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

2 years 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

2 years 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

2 years 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

2 years 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

2 years 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

2 years 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

2 years ago
Depends on: 1397365

Comment 76

a year 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

a year ago
This is what just opened saved session looks like.

Comment 78

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

Comment 79

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

Comment 80

a year 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 82

a year 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
status-firefox57: affected → wontfix

Comment 83

11 months ago
I did not see this mentioned (my apologies if it was), but if a new tab created through opening a link is blocked from loading in browser.webRequest.onBeforeRequest and then Firefox is shut down, the tab will have a blank title if it is restored when Firefox is restarted.  The tab can be clicked on and it will load properly.  Is it possible to have those tabs restored with the title they had previously, which was the part of the url without the scheme?  This could be of use to an extension that delays loading of a new background tab for a short while or until it is selected, but the user exits Firefox before it has loaded.

Another way to duplicate this is to create a new tab by selecting a bookmark with one of the following URLs:

http://example.com:81/
https://www.google.com:81/

These are links that will take a while to timeout.  If the focus is not on the new tab and Firefox is shut down before the tab has timed out, the tab will have a blank title when it is restored by Firefox on a restart.  The same can happen to any new tab created through a bookmark (or link) if Firefox is shut down quickly enough, usually before the tab's title has updated.
(Assignee)

Comment 84

11 months ago
There likely is more room for improvement in terms of making session restore more reliable, but I think we're done here in the sense that the original regression is resolved.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.