Strange behavior when starting Private Browsing

[pflammertsma]

Initially I thought my sessionstore.js was corrupted, and I posted this bug report on Bugzilla, but I pinpointed the problem to be Session History Tree. From the issue:

Firefox was closed while in Private Browsing mode. After reopening it, I
noticed that all my tabs appeared as blank pages, and that I needed to reload
them manually.

Curious if this was related to Private Browsing, I tried switching to that mode
again. Nothing appeared to happen, so I pressed it again. Now, my two pinned
tabs became unpinned, but otherwise, again, no effect. A third press finally
brought me to Private Browsing.

I stopped Private Browsing, which immediately brought all my tabs back.

Now, every time that I start Firefox, my tabs appear blank. I have resolved
this by renaming my sessionstore.js, which appears to have somehow become
corrupted. I have a backup of this file if that is useful for debugging the
problem, but it contains login tokens to work-related websites.

I would be happy to attach the file if anybody can tell me how to strip this
information.

To give a clue: the sessionstore.js is very large (700kb) and contains 1 tab
item with 50 entries, each with about 5 children. The impression I get when
switching to Private Browsing is that the windows are somehow internally
stacked, and that Firefox is opening the pages on top of each other, so to
speak.

Reproducible: Always, with the provided sessionstore.js

Steps to Reproduce:

1. Start Private Browsing
2. Exit Firefox
3. Start Firefox

Actual Results:
All tabs are blank. Switching back to Private Browsing takes several attempts,
between which tabs appear to jump.

Expected Results:
Pages reload and show content. Switching back to Private Browsing is
instantaneous.

If you want me to do some testing with the sessionstore.js, I'd be happy to
comply. I can also try this in Fx 4.2a1.

[ddawson]

I hope you're not using this while you have critical data in your sessions. There's a reason this is marked as "experimental", with version number 0.1a1, etc. Besides potential issues like these, I have other concerns, such as the possibility of the tree not getting written if the session store rejects it (I thought I had read somewhere about there being a limit to the amount of extra data that can be stored, though I might be mistaken).

Anyway, I'll see if I can reproduce this myself. I'll only ask for your sessionstore.js as a last resort.

[pflammertsma]

Fear not, it was nothing critical. I'm pretty safely set up here, anyway, with Xmarks and Lazarus, so even then it wouldn't be a big deal.

A stripped version of a broken sessionstore.js is attached to the Bugzilla issue. I can reproduce the problems using that file.

[ddawson]

It looks like the tree data in your sessionstore.js has been doubly stringified. That shouldn't happen.

The tree is stored internally as a hierarchy of objects and arrays. When written to the session store, it has to be converted to a string, which I do with JSON.stringify(). But at some point it got read out, not parsed, and then stringified again and rewritten.

After some more investigation, I found where this is occurring: at sessionHistoryTree.jsm line 154 I read out the value from session store but forgot to parse it. I've fixed that bug now.

I repaired the tree data and tried starting the browser with that. Now I can see the bug you're talking about. (I think the reason I experienced the above and you didn't might actually be due to the settings for startup, because until I set it to "restore windows and tabs" I only got your two pinned tabs. But whatever.) It looks like this is a special case of this add-on not liking to have its data restored, as with switching in and out of Private Browsing or restoring a browsing session. I should probably file that as an issue.

In the meantime, you can track this repo if you like; I already committed the fix for the multiple stringification. When you want to test, you'll need to make your own XPI, which is just a ZIP file with a ".xpi" extension, where everything in the main directory goes into the archive's root. Be sure to leave out the .git directory, unless you like a much-larger-than-necessary file.

[pflammertsma]

Great! I'll just take your word for it that it's resolved. As the developer of TryAgain, I'm familiar with building XPIs. I'll give it a run when I have a little more time.

Thanks for looking into it so extensively!

[ddawson]

What?! No. No, this issue is not resolved. If it were resolved, I would have marked it as resolved. The problem with screwing up the tree data by stringifying it multiple times is resolved (by 433c41f). This issue, however, is not resolved, and is probably not even close to resolved, seeing as I haven't begun to deal with it just yet and it looks to be tricky. But I will be looking into it.

[ddawson]

Okay, I've addressed the state restoring issue in e7ac3ea. That should fix this as well, except for one thing: there still seems to be a problem if a tab is opened with an invalid URL, and when I try to Start Private Browsing on 4.0, it tries to open about:privatebrowsing, which is considered invalid (how did they let that out in the final release??). Do you see that, or does it bring up an actual message? If the latter, you should be fine; if not, you might work around it by opening another tab after starting Private Browsing. In any case, I don't think it has any effect outside that one tab.

Also, they seem to have fixed their oversight after 4.0.

Please test and let me know how it goes.

Next thing I need to fix is to remove lingering event handlers when page load is stopped, which are another source of tree corruption.

[pflammertsma]

I'm not sure what you mean with Fx bringing up a message. Entering about:privatebrowsing (or any about page, e.g. about:neterror) seems to just show an internal page that also appears in the browsing history. I haven't actually gotten my hands dirty looking into the code.

I would like to give you a hand in testing it, but I'm afraid I simply don't have much spare time on my hands to do so. I'll give the latest build a shot, but as you might have noticed, it's fairly difficult to diagnose the problem. What is it exactly that I can do to figure out when the tree becomes corrupted?

[ddawson]

Oops, looks like I wrote this yesterday and forgot to actually post it. Lazarus FTW.

Well, @sumguy has described a problem (under issue #2) that seems very similar to yours. The common element is that several tabs are being restored (apparently more than the value of browser.sessionstore.max_concurrent_tabs, and only that many are actually restored without having to use "Reload"). I think I'm getting closer to the real cause, and it looks like it might be a Firefox bug after all. See issue #3. I also posted a message on Mozilla Add-ons Forum at https://forums.mozilla.org/addons/viewtopic.php?f=7&t=2886 to see if anyone there can see something I'm doing wrong, which there very well could be. If not, I'm taking this back to Bugzilla.

[ddawson]

Here's a screenshot to show what I mean about the error. I see it only on Fx 4.0; later versions seem to have fixed it. This is on Linux. But you're using Windows? So, I guess it's a Linux-only bug. Or something. In any case, I think it's a minor concern.

About testing, I just meant try out the latest commit and see if you're still having the same problem. But after finding what I described in the previous comment, it's clear you will. jorgev said he thinks the bug is valid. So I think I will definitely file on Bugzilla.

[pflammertsma]

That error message must be Linux-only, I gave it a swing in every version between Fx 1.0 and 4.0, and can't get that message (at least for about:neterror, since the private browsing functionality exist beyond 3.5).

I've noticed issue #2 as well, but thought it was a symptom of this. I would go ahead and suggest you post it on Bugzilla, since all signs point to it being a bug in Firefox. If not, then at least you'll have an idea of where the problem's coming from.