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.

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

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

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.

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.

Also needinfo Mike as this is pretty important and we need a fix asap.

(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.

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

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

(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.

(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()");

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

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]:

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

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.

Windows 2012 pgo build: https://queue.taskcluster.net/v1/task/W6nndR7xTweyqCYMvBI-lA/runs/0/artifacts/public/build/target.zip

Mac opt: https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-release-macosx64/1502290970/firefox-55.0.1.en-US.mac.dmg

(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! )

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!

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.

Comment on attachment 8895378 [details] [diff] [review] Bug-1388628.diff I landed it in m-r

Bug 1373902 may be a duplicate ?

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.

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.

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

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

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

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?

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?

(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?

yeah, I confused this bug with bug 1388584. sorry :/

(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! :)

Comment on attachment 8896129 [details] [diff] [review] patch for beta uplift: disable reusing the selected tab Approval Request Comment see comment 17

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

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.

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.

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.

(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.

I'm on OS X.

maybe related to bug 1366477? 32bit win10

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

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.

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

(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

Since this goes beyond just version 55, should that get taken out of the bug title? Thanks.

indeed!

(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.

(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

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

(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

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?

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

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).

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?

(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.

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.

(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"

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.

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)

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.

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.

> … 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/>.

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

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

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

This is what just opened saved session looks like.

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

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

(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.

(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.

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.

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.