Closed Bug 551285 Opened 11 years ago Closed 11 years ago

Drop backwards compatibility for Firefox 2/3

Categories

(Firefox :: Session Restore, defect)

defect
Not set
trivial

Tracking

()

VERIFIED FIXED
Firefox 3.7a4

People

(Reporter: zpao, Assigned: zpao)

References

Details

Attachments

(1 file, 1 obsolete file)

We're now several releases from the last time that was used (3.0) & we might as well clean it out.
Attached patch Patch v0.1 (obsolete) — Splinter Review
Get it gone.
Attachment #431490 - Flags: review?(zeniko)
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)?
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.
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?
(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.
(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).
Attached patch Patch v0.2Splinter Review
(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.
Attachment #431490 - Attachment is obsolete: true
Attachment #431929 - Flags: review?(zeniko)
Attachment #431490 - Flags: review?(zeniko)
Attachment #431929 - Flags: review?(zeniko) → review+
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?
(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);
Ah ok.  For some reason I thought I needed the entire XPath, not just the end part of it.  

Thanks.
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?
Pushed http://hg.mozilla.org/mozilla-central/rev/55b6bc4c0b92
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Summary: Drop Support for Firefox 2/3 tabData.text → Drop backwards compatibility for Firefox 2/3
Target Milestone: --- → Firefox 3.7a4
Is there anything QA can check for to verify this bug?
Blocks: 561719
(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.
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.