Nightly refuses to resume session after update

[Drumbrake]

I've just run into this weird issue:after todays's Nightly update to firefox-35.0a1,upon restart the browser hangs with just one tab open (I'm trying to restore a large session with hundreds of tabs arranged in 8 windows) and it's impossible to restore the session.
I've tried safemode,moving around sessionstore files,there's no way to recover this session with the current Nightly-however,and here's the really weird thing,I've made a copy of the entire profile and launched it with the current release version 32:no issues at all,the session is opened normally.
So it's really the current Nightly that refuses to open this very session,even in safe mode:any ideas on what I should look for,in case they are known bugs already?
I would file a bug,but this is kinda tricky to explain and probably to reproduce,so I have to ask here first.
For the record,I haven't enabled e10S.

Do you think that,in case during this last update something inside the browser's directory itself (not the profile's directoty) got corrupted ,downloading the current Nightly again from Mozilla's server and starting from scratch would be worth trying,BTW?

[therube]

Corrupted?

Unlikely I'd think.
Can't hurt to try.

So "today's" (yesterday now, I suppose) Nightly failed.
What about the day before today's, did that work?
Or the day before that?
Or is the first Nightly you have tested with?

Anything related noted in Error Console?

You've kept a backup copy of this non-working sessionstore.js file?
You can always submit that with your bug report.

Suppose you've tested in a new, clean Profile, the only addition being the existing sessionstore.js?

[Drumbrake]

Updates so far have been working "normally" for a Nightly:sometimes they failed or couldn't be applied,so I've just downloaded the latest Nightly and took from there.

Never so far I've been unable to recover the previous session:the weird thing is,the exact same profile starts normally with the current release version (Firefox 32),and there's more,as creating a clean profile and then transplanting just sessionstore.js also allows to recover the session.

So why the latest Nightly hangs on start up and won't resume this session,not even in safemode?

That sessionstore.js file apparently isn't corrupted,so assuming that it could be some incompatible addon messing things up,why doesn't safemode work?
Shouldn't safemode go around any incompatible addons issue,by actually disabling them all?

Maybe,even if I haven't enabled e10s,something related to e10s may be still causing this?

[Drumbrake]

I'm still banging my head against this (metaphorically,so far):after downloading again the current Nightly and trying to reuse the same profile,predictably nothing changes,as I still can't recover the session.
To sum up:
-after a recent update,I couldn't recover my current (massive) Nigthly session on restart.
-an exact copy of the same profile still works normally with the current release version
-starting a clean,new Nightly profile,closing it and then pasting into it only the
sessionstore.js file from the original profile kinda works,as the session can be restored either from the history menu or about:sessionrestore.
-bookmarking all tabs from that session in that clean new profile,exporting them to an html file,and then re-importing/opening them in the problematic profile doesn't work:I can obviously open them all,but then on the next restart the entire session is lost again.
-also directly grafting the sessionstore.js file from the clean new profile to the old one doesn't work.

I've then grabbed a debug build from the ftp server and started it from a terminal,the log is kinda long,however I can see a lot of lines like these repeated over and over:

Code: Select all

addons.xpi   ERROR   Failed to load bootstrap addon jid0-R9xPsoETsjTKZQNYZbycVxlHj4w@jetpack from /home/.mozilla/nightly/extensions/jid0-R9xPsoETsjTKZQNYZbycVxlHj4w@jetpack.xpi: [Exception... "Unexpected error in XPConnect"  nsresult: "0x80570008 (NS_ERROR_XPC_UNEXPECTED)"  location: "JS frame :: resource://gre/modules/addons/XPIProvider.jsm :: XPI_loadBootstrapScope :: line 4307"  data: no] Stack trace: XPI_loadBootstrapScope()@resource://gre/modules/addons/XPIProvider.jsm:4307 < XPI_callBootstrapMethod()@resource://gre/modules/addons/XPIProvider.jsm:4408 < XPI_startup()@resource://gre/modules/addons/XPIProvider.jsm:2159 < callProvider()@resource://gre/modules/AddonManager.jsm:208 < _startProvider()@resource://gre/modules/AddonManager.jsm:667 < AMI_startup()@resource://gre/modules/AddonManager.jsm:821 < AMP_startup()@resource://gre/modules/AddonManager.jsm:2393 < AMC_observe()@resource://gre/components/addonManager.js:55 < <file:unknown>

Should anyone of the resident pundits have a clue,I'm all ears..
If anyone is interested in the log,I could maybe post it or upload somewhere.

[BenYeeHua]

Yup, that log is showing your addon.
https://github.com/lrem/enjoyreading2/b ... ckage.json

[Drumbrake]

Hi,but that's only the start of the log:similar lines can be seen for almost every addon I have installed,as far as I can see.
Do you want to have a look at the entire log?
Or can you point me to possibly related bugs?

[therube]

> Any change in non-working Nightly if you open it is Safe Mode?

Tried & didn't work.

Any change in the working Nightly if you copy over non-working prefs.js (& user.js)?

If that still works, I'd start copying things over one at at time, restarting each time to see if it breaks.
After .js, perhaps jump to .rdf.
(Heh. I guess after those two, there won't be much left.)

[Gusar]

Delete the startupCache. On Linux, it'll be in ~/.cache/mozilla/firefox/profilename, no idea where it's stored on Windows. But basically, whenever I saw this issue, deleting the startupCache solved it.

[Drumbrake]

Delete the startupCache.

Done earlier on,and I've also deleted anything else than I could think of:that session can no longer be opened in that profile,as far as I can tell

Apparently,the only thing left to do is indeed to start over with a clean profile and move stuff in one thing at the time to find what is causing the breakage-still,it puzzles me that when using the same profile (I do mean,an exact copy) with a release version,everything is still working.

[therube]

> it puzzles me that when using the same profile (I do mean,an exact copy) with a release version,everything is still working

And is that necessarily unexpected?
After all you're comparing a release against a Nightly.

[Drumbrake]

I've maybe pinned down the issue:setting dom.indexedDB.enabled to false,as I've been doing for a while now,apparently breaks session restore in the latest Nightlies (it didn't before) and also messes things up with some addons (noticeably,Adblock) that can't be upgraded/removed/installed.

In case you wondered why I was disabling it:

IndexedDB is an API for client-side storage of significant amounts of structured data and for high performance searches on this data using indexes

https://developer.mozilla.org/en-US/doc ... exedDB_API

Currently 3rd-party content (frames) can use databases. We want to block 3rd party because it's easier to loosen restrictions than the reverse. bug 595307

https://wiki.mozilla.org/Security/Revie ... ity_Review

I'm not to keen about this storage method.

[Drumbrake]

Thinking again of it,why should session restore rely now on the IndexedDB storage,and furthermore why should Adblock depend so much on it that it can't even be installed without enabling it ?

[Virtual_ManPL]

because of better performance and asynchronous support probably...
why would you want disable this database support in the first place?

[Drumbrake]

because of better performance and asynchronous support probably...
why would you want disable this database support in the first place?

In case you wondered why I was disabling it:

IndexedDB is an API for client-side storage of significant amounts of structured data and for high performance searches on this data using indexes

https://developer.mozilla.org/en-US/doc ... exedDB_API

Currently 3rd-party content (frames) can use databases. We want to block 3rd party because it's easier to loosen restrictions than the reverse. bug 595307

https://wiki.mozilla.org/Security/Revie ... ity_Review

I'm not to keen about this storage method.

And,come to that,about anything/anyone who wants to permanently store something on my computer,especially if I'm not aware of what exactly is.

[Virtual_ManPL]

How are you not aware what exactly it is?
Can't you check these files and see what is inside of them or their content?
About Adblock Plus or Session Manager that you mention... no wonder why it doesn't work properly when you disable IndexedDB which is probably used for storing filter subscriptions and sessions data.

Don't be so paranoid...