Open GoogleCodeExporter opened 9 years ago
GoogleCodeExporter
commented
9 years ago 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
commented
9 years ago 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:
GoogleCodeExporter
commented
9 years ago [deleted comment]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
commented
9 years ago 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
commented
9 years ago 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:
GoogleCodeExporter
commented
9 years ago 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
commented
9 years ago [deleted comment]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
commented
9 years ago 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
commented
9 years ago Original comment by micha.go...@arcor.de on 21 Feb 2015 at 2:17
GoogleCodeExporter
commented
9 years ago 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:
Original issue reported on code.google.com by
s...@eftegari.comon 11 Feb 2015 at 8:41