Incomplete Session Restore (beta 005) Missing All Suspended Groups!

[GoogleCodeExporter]

I have 15 groups: 1 ACTIVE and 14 SUSPENDED groups. Totalling around 200 tabs 
spread over the various groups. I manually export my session file (around 800 
kbyte) as a backup.

When I manually restore this backups back to FF, then ALL SUSPENDED GROUPS are 
lost. Only the active group are restored.

This is with the newest beta 005!!

When I activate several groups and manually export it, then restore it back, 
again: only the active groups are restored.

FF 32.0.3   TGM latest beta 105 (005)    Win7 64 bit, 16GB ram, SSD
No plugins except adblock plus and adobe flash, without which I cannot imagine 
any FF user could use TGM! So this is a big problem for us TGM users indeed, 
and its easily reproduced.

Original issue reported on code.google.com by s...@eftegari.com on 11 Feb 2015 at 8:41

[GoogleCodeExporter]

Do you have activated start with last session in Fx options?
We know that there is a problem with suspended groups. See issue 47 comment 
25/1st paragraph.

What happens if you start only with about:blank and the manually import the 
session?

Original comment by micha.go...@arcor.de on 12 Feb 2015 at 3:45

[GoogleCodeExporter]

I doesnt know if this are good news.

Looks like the problem is sessionstore related. As well known, the session 
stuff of websites will be saved into sessionstore firefox files (as also TGM 
files).  I have tested various fx builds between 22 - 35 with different TGM 
betas. Always with same urls and i was not able to reproduce this. Then I took 
an url from my defective test profile and added this url into the fx and saved 
the session manually again:

https://play.google.com/store/apps/details?id=org.mozilla.firefox&referrer=utm_s
ource%3Dmozilla%26utm_medium%3Dbanner%26utm_campaign%3Ddesktop01

After next restore of session with a suspended group started the lost suspended 
group disaster. 

Will still test again what is happening with the old Fx & TGM versions with 
this new facts. But it looks like the session content self destroys the 
functionality of restoring suspended groups at the moment.

Original comment by micha.go...@arcor.de on 12 Feb 2015 at 6:11

Attachments:

• backup_data_manually_2015_02_12_18_01_04_0.tgm2
• backup_data_manually_2015_02_12_18_39_02_0.tgm2

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thanks for the thorough experiments!

Does this mean that some URL's are the cause of the corrupted TGM2 files?
And that for some reasone these URL's are causing our incomplete session 
restore?

Original comment by s...@eftegari.com on 12 Feb 2015 at 6:31

[GoogleCodeExporter]

Not the urls, but the session data stored for this websites. I was able to add 
other websites and nothing happens, then i took the above mentioned website and 
it stops to work.

Original comment by micha.go...@arcor.de on 12 Feb 2015 at 7:00

[GoogleCodeExporter]

It starts with Fx 29. Its not related to beta 3,4 or 5. The format of 
sessionstore is changed and together with sessiondata from specific websites we 
got this problem. Would be nice to have a parser for the sessionstore files to 
visualize the structure of sessionstore for humans. But at the first look there 
is closedAt added and global object added at the end. And for Fx 35 or earlier 
there is again a new structure....but from 28->29 seems to be most interesting 
for this moment.

Original comment by micha.go...@arcor.de on 12 Feb 2015 at 7:53

Attachments:

• sessionstore27.js
• sessionstore29.js

[GoogleCodeExporter]

Analyzed the json objects from sessionstore and tgm files yesterday. Learned 
that its not the stored session data self that is responsible here. I changed 
the playstore.google url to www.google and was surprised that the suspended tab 
was restored. Looks like non www urls get a other treatment and need more time. 

In fact all this here is a timing problem. During investigation found out that 
groups will be restored after a async message was send in fx internal 
sessionstore scripts. This async stuff comes due the ongoing E10 multiprocess 
development.

I have setup a delay with settimeout and i get my testcase to work. But this is 
only a workaround and no solution. Better to wait for a event or one of these 
E10s messages. Needs further investigation.

We have definitely a problem here and the TGM is not designed to handle the 
async E10s stuff...and TGM is no small addon.

Original comment by micha.go...@arcor.de on 15 Feb 2015 at 10:15

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Really interesting and thank you so much micha for taking the time to guess it. 
Hope I can take some time soon and also take a look at it with you.

Original comment by miguelro...@gmail.com on 15 Feb 2015 at 11:44

[GoogleCodeExporter]

Its was really only the timing due the async stuff in sessionstore. I have 
asked fx devs why they use content scripts and async messages. It was not for 
E10s, it was to reduce jank for session restore...

My first step was to place a settimeout to the jsm, but this was only move the 
code execution to a time where not was so much cpu load and helps to override 
the problem.

Every time if a tab will be restored SSTabRestoring will fire. The problem was 
that the function saveAllGroupsDataImmediately will always be called on this 
event.
The function self fetches the data from the still incomplete groups and save 
data to the fx sessionstore object. And all this manipulates also the loaded 
data from file and the next group restorings. So success or not success for 
group restoring (at least with suspended groups) was more or less depending 
from time of tab restoring (or url).

As next I deactivated the saving to the sessionstore object and all was fine, 
the groups was restored properly. A settimeout on this place was also working, 
but i found a TGM variable groupRestored to control the access in 
saveAllGroupsDataImmediately(). Now, we save only data if grouprestored is in 
state 2 = restored.

It tooks much time to learn whats going on during session restore. It was 
difficult to debug. Things what are working in real time are not working in the 
debugger - due the event controlled program flow and vice versa...what was not 
working in real time works in the debugger. Happy debugging!

I will check it the next 1 or two weeks before check in to get sure that we not 
run in other problems now.

Original comment by micha.go...@arcor.de on 21 Feb 2015 at 12:55

[GoogleCodeExporter]

Original comment by micha.go...@arcor.de on 21 Feb 2015 at 2:17

• Changed state: Started

[GoogleCodeExporter]

Awesome Update Micha.go!

Visual comparison of both. A very tough puzzle!

Original comment by s...@eftegari.com on 2 Mar 2015 at 12:13

Attachments:

• Compare.png