1308597 - Windows do not appear on Restart with 32-bit OS

Status: RESOLVED WORKSFORME

(Firefox :: Session Restore, defect)

Description

[Barry S. Finkel]

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

Comment 1

[Vlad Bacia-Mociran [:VladB]]

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.

Comment 2

[Barry S. Finkel]

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.

Comment 3

[Vlad Bacia-Mociran [:VladB]]

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.

Comment 4

[Barry S. Finkel]

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.

Comment 5

[Barry S. Finkel]

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

Comment 6

[Vlad Bacia-Mociran [:VladB]]

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.

Comment 7

[Barry S. Finkel]

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

Comment 8

[Vlad Bacia-Mociran [:VladB]]

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.

Comment 9

[Barry S. Finkel]

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

Comment 10

[Wayne Mery (:wsmwk)]

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]

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 12

[Barry S. Finkel]

I have not had this problem in the recent past. I have since converted from Windows 7 32-bit to Windows 10 64-bit. I suggest that you close this as not now reproducible.

Comment 13

[Wayne Mery (:wsmwk)]

Barry, Thanks for the update