1247551 - Nightly 47 irreversibly corrupts FireFox 45's session (with screenshots)

Status: RESOLVED WORKSFORME

(Firefox :: Session Restore, defect)

Description

[User Dderss]

Attachment: Nightly 47 corrupts session that is fine in FF 45.png

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160208194709

Steps to reproduce:

I was tired to FireFox 45 never allowing me quick restarts/closing due to #bug 1219586 and #bug 816784 -- where this process takes forever, FF's memory footprint blows up (!) and after few minutes gets abruptly ended probably due to timer limitation, always causing a crash. So I wanted to try Nightly again, downloaded latest build from today, and ran it.


Actual results:

During run I got "Restore session" tab (due to obligatory crash in previous exit), I clicked on "Restore", which always works in FF 45. As seen in attached screenshots, session opened with full number of tabs as it should, but all tabs were empty with "New tab" titles. Attempts to restart session did not work out. Turning e10s mode on did not work either -- I have got low level FF scripts busy/non-responding, as shown in other two attachments. 

I had to recover my session from separate archive, because, of course, just returning to FF 45 did not help to restore session. Session management is not good enough to understand that if there are a lot of tabs but they all are EMPTY, then something wrong has happened, and hence FireFox should offer recovery, not just rewrite/erase older recovery files for the session with the new corrupted/empty session.


Expected results:

Restore function in Nightly 47 should not irreversibly corrupt session.

This probably happens because Nightly 47's restore function is updated to recover Nightly 47's session, not FireFox 45's session. As result, session gets destroyed. The issue is that in my case there is no way to exit from FireFox 45 without crash, so session can not be repaired in FireFox 45.

Comment 1

[User Dderss]

Attachment: Nightly 47 -- BrowserXML script is busy or not responding.png

Comment 2

[User Dderss]

Attachment: Nightly 47 -- TabLibJS script is busy or not responding.png

Comment 3

[Loic]

Honestly, you should never use the same profile with different versions, especially from Release/Beta to Nightly.

About the session restore broken and opening a bunch of blank tabs, what are your settings about cookies management? Did you uncheck the option "Accept cookies from sites"?

Comment 4

[User Dderss]

Cookies-related options were not changed recently, if ever at all. I do not even remember where this "Accept cookies from sites" option is.

I have been switching/jumping back and forth between Release, Beta, Aurora/Developer Edition and Nightly for many years, it usually works just fine with the same profile. So, as I wrote above, my main guess is that FireFox 45 session was corrupted during first launch of Nightly 47, and session recovery only properly works -- without destroying anything -- with corrupted Nightly 47 sessions, not with corrupted FireFox 45 sessions.

Of course, the root cause is that FF 45 can not exit without crash -- hence, without corrupting session -- if it has significant number of tabs. But still I suppose Session Restore function in Nightly 47 should be updated to process older FireFox corrupted session without destroying it.

Comment 5

[Loic]

about:preferences#privacy > Use custom settings for history > Accept cookies from sites

Comment 6

[Loic]

But IMHO, it's just another case of bug 1238178 due to broken session sessionStorage component.

Comment 7

[User Dderss]

(In reply to Loic from comment #5)
> about:preferences#privacy > Use custom settings for history > Accept cookies
> from sites

The settings says to "Always" accept cookies and store them until their expire, so it is different from #bug 1238178

Comment 8

[Wayne Mery (:wsmwk)]

Does the same issue reproduce using a current nightly build, started in safe mode?

Comment 9

[User Dderss]

Since I FF 45->FF 47 upgrade was one-time event for me, I can not attest to whether corruption of session can still happen or not. The issue at hand is that session management has to be updated in a way to never ever let it happen again. Those few copies of user's active session somehow all got corrupted, and this should be impossible. So maybe this bug should be transformed into software/architecture change request type of bug.

As to crashes on exit, they continue as #bug 816784 is not yet resolved, it continues with the slightly different crash signature as in #bug 1279293. There is chance that a combination of those bags with user updating FireFox from one version to another can still cause the catastrophic destruction of other users' sessions as I have experienced.

Comment 10

[Loic]

Let's close it as you're not able to reproduce it. File a new bug if the issue is back.

Comment 11

[User Dderss]

It is not a type of bug that could be reproducible for anyone other who had #bug 816784 and/or #bug 1279293 related corruption AND, simultaneously, who upgraded into a new version of FF.

As I mentioned, the issue at hand is not about specific patch for this specific situation, but about session management. It has to be updated in a way to never ever let session to be corrupted the way described in this bug. During FireFox upgrade there is some function that processes previous stored session to check/upgrade it to the form, necessary for the newer version of the browser, and somehow it was totally fine with presenting user a session without any URLs in many tabs that session had. 

It should not be very hard to make a session integrity checker function that would see if resulting/upgraded session has lost actual URLs within tabs, and hence it would not let the FF just to accept this new corrupt session as if it is a fine one, as it has happened in this bug, and, hence, replacing session's copies in the process to a point where user would have lost his/her session forever, if it was not saved by third party software like Cobian Backup.


Loic, how we can transform the bug into software/architecture change request type of bug? Just closing it makes no sense, this bug has to be used for something productive.

Comment 12

[Loic]

I dunno.

Comment 13

[User Dderss]

I checked how to do it: as in #bug 515352, for example, we have to set status of this bug as "new". It does not mean that specific patch is necessary, it means that there is some work/discussion to do on feature request/partial software redesign. Please change the status of this bug this way, as I somehow have no such option. Thank you in advance.

Comment 14

[Loic]

Unconfirmed is fine.

Comment 15

[Wayne Mery (:wsmwk)]

Do you still encounter this problem when using newer Firefox?

Comment 16

[User Dderss]

No, I am not facing this type of disastrous crash recently.

Comment 17

[Wayne Mery (:wsmwk)]

Thanks for the update. Please update the bug if you see the problem again.