Windows do not appear on Restart with 32-bit OS

UNCONFIRMED
Unassigned

Status

()

Firefox
Session Restore
--
critical
UNCONFIRMED
a year ago
a year ago

People

(Reporter: Barry S. Finkel, Unassigned)

Tracking

(Depends on: 1 bug, {dataloss})

47 Branch
x86
Unspecified
dataloss
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [dupme])

(Reporter)

Description

a year ago
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160623154057

Steps to reproduce:

I have a FF configuration that has 14 windows.  FF crashes frequently (but that is not the topic of this bug report).  When I start FF, sometimes I do not see all of my 14 windows.  Sometimes 1 or 2 is/are not shown.

This is FF 47.0.1 on a Windows 7 Professional 32-bit system.


Actual results:

What I do in this case is to determine which window(s) is/are not visible.  Then in an existing window I open a new tab and enter part of a URL in a "hidden" window.  FF will then ask me if I want to go to that existing tab.  When I click to do so, the "hidden" window then becomes visible.


Expected results:

When I restart FF, all of the 14 windows in my sessionstore.js (or one of the backup files) should start and be visible.  I have a saved sessionstore.js file (15 Mb) that I can provide.  I assume that if someone uses this configuration file and repeatedly Exits and restarts FF, then the problem will occur, and the problem can then be debugged.

Note that I always start FF in safe mode (without add-ons).
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0

I have tested your issue on latest Firefox release (49.0.1) and latest Nightly (Build ID: 20161011030212) and could not reproduce it. I have opened 14 random browser windows with different content and after that I've restarted, closed and started again the browser multiple times, every time all browser windows were opened and displayed. There was no crash. I also used session-manager add-on for Firefox and all windows were displayed. 

Can you please retest this using latest FF release and latest Nightly build (https://nightly.mozilla.org/) and report back the results ? When doing this, please use a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause (https://goo.gl/PNe90E). Please try also with the add-on.
Flags: needinfo?(bsfinkel)
(Reporter)

Comment 2

a year ago
Vlad, as I just wrote in reply to my other bug report (1308583), please test this with my sessionstore.js file.  There are issues related to this problem:

When I start FF, I look at the sessionstore-backups directory to see the timestamps on the recovery.{bak,js} files.  After I go to a new tab or close an existing tab, a new restore.js file is written.
After FF has been running for a while (47.0.1, as 48.0 is not up long enough for me to do anything),the restore.js file is not written. For example, I used an existing "create account" tab, and I changed the URL to the URL for this trouble ticket.  This was about 10 minutes ago, and it is now 13:16.  But the restore.js file still has an 09:04 timestamp.

Also, after FF has been running for a while, I do an Exit (when FF is beginning to be unresponsive).  Sometimes FF does a clean termination (no dump), but a sesionstore.js file is NOT written.
Flags: needinfo?(bsfinkel)
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0

I could not reproduce this issue using latest Nightly (Build ID: 20161016030205). I've created a new Firefox profile and from `about:preferences` the `Show my windows and tabs from last time` option was set. I've opened multiple windows with multiple tabs and changed the URLs from some opened links. "recovery.js" file from the profile used was updated with the last changes.

Please retest this issue with latest Nightly build (https://nightly.mozilla.org/) and report back the results.

Due to the fact that the issue is reproducible for the reporter I will assign a component and perhaps there's someone with extensive knowledge on this area that might be able to help here.
Component: Untriaged → Session Restore
Flags: needinfo?(bsfinkel)
(Reporter)

Comment 4

a year ago
Sorry for the delayed response.  I was away from my computer for a few days.
I have two questions.  
1) Did you run your tests on a Windows 7 32-bit system?  Maybe my problem is resource-limit-related, and the problem would not occur on a 64-bit version of Windows.  And maybe my problem is due to something in Windows 7 but will not occur on Windows 8.1.  I have a Win 8.l 64-bit system on which I can try my sessionstore.js file.  A 64-bit OS can utilize more memory than a 32-bit version; if my problem is related to a memory shortage situation, it might not occur on a 64-bit OS.

2) What is the base version for the latest nightly build?  Is it 48.0.1?  I want to look at the release notes for 48.0 and its successors to see what changes were made.  Something was changed in 48.0 (over 47.0.1) that causes FF to crash with 48.0 before I get a chance to do anything.

Note that these two questions also apply to my other bug report - 1308593.
Flags: needinfo?(bsfinkel)
(Reporter)

Comment 5

a year ago
I am assuming that with my sessionstore.js file you may be able to reproduce this problem on a Windows 7 32-bit system.  I have no idea if the problem exists on 64-bit Windows systems or on 32-bit Windows 8.1 systems.  Another problem that I am researching is related - sometimes after some (as yet unknown) event, FF does not store a new recovery.js file when I open a new tab.  And sometimes, a clean Exit does not store a sessionstore.js file.  These two may be related, but I have not yet concluded my research into the 47.0.1 source.  But this, if I find anything, will be a new problem and not part of this vanishing windows problem.

--Barry Finkel
Flags: needinfo?(bsfinkel)
I cannot reproduce this issue on latest Firefox release v49.0.2 and neither on latest Nightly (Build ID: 20161023030206) using Windows 7 x86, because Bug 1308593 it's a blocker. On Win 7 x64 and Win 8.1 x64, this issue is not reproducible.
Depends on: 1308593
(Reporter)

Comment 7

a year ago
I am not sure exactly what you mean by "its a blocker". I am assuming that any FF version after 47.0.1 will not stay up long enough for you to do anything to test this problem.  I assume that if you use 47.0.1 on Win 7 32-bit, as I am running, you would be able to reproduce the problem.  I would not mind if you spent your time on 1308593 instead of this one, as that one is more important to me.

And I will probably open another related bug report early next week. after I have had time to do more research with the source.

--Barry Finkel
Flags: needinfo?(bsfinkel)
As I mentioned above in comment 1, I cannot reproduce this issue on a x64 Widnows version. On the x86 Windows version if I use a scenario in which I have 14 browser windows opened and about 100 tabs, I cannot reproduce this issue. 

With the sessionstore.js file that you provided (14 browser windows and 1125 tabs), I cannot test this issue because the browser crashes or becomes unresponsive.

Maybe this article (https://goo.gl/c3c1Hj) from Mozilla Support page will be of assistance to you. Or you may use Session Manager add-on as a workaround until this issue is resolved.
(Reporter)

Comment 9

a year ago
As I cannot attach at 15 Mb file to this problem record, here is a Dropbox link to my sessionstore.s file:    https://www.dropbox.com/s/8jx1tz1gkolrfwn/sessionstore.js?dl=0

I will wait for a resolution to my 1308593 bug before I expect a response on this one.

--Barry Finkel
Your loss of sesionstore.js is not likely to be specifcally caused by crashes.

You should look in browser console / error console to find things relevant to memory usage and sessionstore (before it crashes of course) ... and, this is probably a duplicate of an existing bug report like one of https://mzl.la/2i0pUVd  (thus -> [dupme]
Severity: normal → critical
Keywords: dataloss
Hardware: Unspecified → x86
Summary: Windows Do Not appear on Restart → Windows do not appear on Restart with 32-bit OS
Whiteboard: [dupme]
You need to log in before you can comment on or make changes to this bug.