551285 - Drop backwards compatibility for Firefox 2/3

Status: VERIFIED FIXED

(Firefox :: Session Restore, defect)

Description

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

We're now several releases from the last time that was used (3.0) & we might as well clean it out.

Comment 1

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Attachment: Patch v0.1

Get it gone.

Comment 2

[Simon Bünzli]

We do have several other code bits related to the format used by Firefox 3.0 and older. Any reason to single out just this bit?

Michael: Does Session Manager rely on modern Firefox to restore a Firefox 2.0 or Firefox 3.0 session? If so, do you consider it possible to internally upgrade the sessions (before Firefox.next comes out)?

Comment 3

[Michael Kraft [:morac]]

It currently does rely on Firefox, but I can modify the session files to be compatible with the latest format since Session Manager is already manipulating the session files for other reasons.

If you come up with the full list (patch files) I can upgrade the session files.

Comment 4

[Michael Kraft [:morac]]

Of course this would likely mean removing 3.0 support from Session Manager since the converted sessions wouldn't work in 3.0.  Probably not a bad idea any way.

I'm assuming SeaMonkey 2.0 uses the post Firefox 3.0 format?

Comment 5

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(In reply to comment #2)
> We do have several other code bits related to the format used by Firefox 3.0
> and older. Any reason to single out just this bit?

I've been looking at that code recently to put some profiling probes in, so it's been in front of me. I'd be more than happy to take out more 3.0- specific code. Most of it isn't hurting, but I like cleaning out old code.

If you agree that this sort of cleanup is a good idea, we can file bugs for the rest (I'm sure I know a few, but you probably have a better idea since I didn't start until 3.5ish).

(In reply to comment #4)
> I'm assuming SeaMonkey 2.0 uses the post Firefox 3.0 format?

Yes. From what I can tell Seamonkey's sessionstore is essentially the same as Firefox 3.5.

Comment 6

[Simon Bünzli]

(In reply to comment #5)
> If you agree that this sort of cleanup is a good idea, we can file bugs for
> the rest

Please just do everything here. Searching for "Firefox 2" and "Firefox 3" should yield all the bits to remove (IIRC, there weren't any breaking changes after 3.5). The only thing to keep are the parentheses added for backwards compatibility (AFAICT, even Trunk still expects these - and that's be the only change resulting in complete dataloss when downgrading).

Comment 7

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Attachment: Patch v0.2

(In reply to comment #6)
> Please just do everything here. Searching for "Firefox 2" and "Firefox 3"
> should yield all the bits to remove

I think this is all of them.

Comment 8

[Michael Kraft [:morac]]

Quick question.  

Looking at the code there doesn't appear to be any real way I can see of to  convert the old form (text) save format to the new form data format with just the session data.  I'm assuming there is no way to convert the form data to the new format short of restoring the page and re-saving it?

Comment 9

[Simon Bünzli]

(In reply to comment #8)
AFAICT, this should be easily possible - just use the iteration we're removing and turn the matches into properties of the formData object:

var key = RegExp.$2 ? "#" + RegExp.$3 : "//*[@name='" + RegExp.$3 + "']";
formData[key] = decodeURI(RegExp.$4);

Comment 10

[Michael Kraft [:morac]]

Ah ok.  For some reason I thought I needed the entire XPath, not just the end part of it.  

Thanks.

Comment 11

[Michael Kraft [:morac]]

One last thing.  The "owner" field.  What exactly is that?

In the old Firefox 2 session format it was stored as a URI.  Later formats it was stored as a binary stream. Would the following work?

var uriObj = IOSvc.newURI(ownerURI, null, null);
var owner = SecuritySvc.getCodebasePrincipal(uriObj);

and then just copy the code that converts owner into owner_b64?

Comment 12

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Pushed http://hg.mozilla.org/mozilla-central/rev/55b6bc4c0b92

Comment 13

[u279076]

Is there anything QA can check for to verify this bug?

Comment 14

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(In reply to comment #13)
> Is there anything QA can check for to verify this bug?

So you can check that Firefox won't restore parts of the session that we dropped support for, namely:
tabData.xultab (I think this was things like busy were saved)
tabData.text (which was how formData was stored)
aEntry.postdata (how history entries post data was saved)
aEntry.ownerURI (meh)
cookies.domain1 (indicated that it was an old serialization format for cookies)

http://blog.zpao.com/post/450728650/partially-dropping-support-for-firefox-2-0-3-0 says which version these all correspond to so you can go back and make sessions with those versions. I would double check that sessionstore.js has those keys in it.

(In reply to comment #11)
> One last thing.  The "owner" field.  What exactly is that?

Err... if this helps - from the nsISHEntry idl: "he owner, if any, that was associated with the channel that the document that was loaded to create this history entry came from."

> In the old Firefox 2 session format it was stored as a URI.  Later formats it
> was stored as a binary stream. Would the following work?
> 
> var uriObj = IOSvc.newURI(ownerURI, null, null);
> var owner = SecuritySvc.getCodebasePrincipal(uriObj);
> 
> and then just copy the code that converts owner into owner_b64?

Yea that should work. I might get around to fixing that part that requires the btoa(), it seems like JSON.stringify is doing better with some special characters. If I get around to it, I'll make sure to CC you on that bug.

Comment 15

[u279076]

This appears to work.  I created a couple profiles (one Fx2, one Fx3).  I then populated sessions in those profiles with form data, post data, and a bunch of cookie data.  I then loaded those profiles in today's Minefield nightly.  The tabs were restored but none of the session data remained (form data, cookies, etc).  I also checked sessionstore.js for the keys as you indicated and they don't exist in the profile after using Minefield.

I think I can call this one verified.