Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20070713 Firefox/188.8.131.52 This is spun off from bug 385882. Steps to reproduce: 1. Tools > Options > Main > Choose "Show my windows and tabs from last time" 2. Go to http://www.mozilla.org/editor/midasdemo/ and input some text. 3. File > Quit 4. Reopen Firefox and try typing into the editor. Actual results: The text that was in the editor is NOT restored and you cannot type anything in the editor. An error is also in the Error Console: Error: uncaught exception: Permission denied to set property HTMLDocument.designMode Expected results: Text is restored and I'm able to edit it. This regressed on BRANCH between 2007-07-11-03 and 2007-07-12-03: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-07-11+02&maxdate=2007-07-12+04&cvsroot=%2Fcvsroot. This issue has been around on trunk since at least 2007-01-01-04, FWIW.
Confirmed, I see this in the error console: Error: uncaught exception: Permission denied to set property HTMLDocument.designMode
Aha! So I tracked down the regression range on trunk to between 2006-08-15-04 and 2006-08-16-04. Bug 332182 landed in this range as well as in the branch regression range I found, so I guess we've found our offender.
Then again, brendan's been arguing for an alternate serialization format for principals. If people can figure out what they want, we could do that too.
(In reply to comment #3) > I assume that session restore can store binary blobs as needed? Since we support JSON serialization, you'd have to manage with strings, IEEE 754 numbers and arrays containing those. An encoded string should probably do the job. > where we do the actual serializing and deserializing in nsSessionStore.js. That's really just _serializeHistoryEntry and _deserializeHistoryEntry which convert a "@mozilla.org/browser/session-history-entry;1" to a JS object and vice versa.
Not blocking the 1.8 branch, but when there's a trunk fix please renominate for the branch.
Created attachment 280766 [details] [diff] [review] Trunk fix This patch requires the fix for bug 369566 to work. It also fixes the bug the existing code had with truncating postdata at the first null, while I was here. jst, could you review the session history part? mconnor, could you review the session store part?
Created attachment 280767 [details] [diff] [review] Branch patch Doesn't really have much to do with the trunk patch, for what it's worth.
(In reply to comment #10) > I have no idea. Catching seems like the safer thing to do, but please add a comment as to that this isn't anything special you're trying to catch (in case the code gets refactored or we want to try without the try-catch-block). > They are, but the JSON serialization doesn't deal. See bug 396068. Hm, our JSON code would really have dealt with that more graciously than toSource which we use here. Fixing bug 387859 would thus prevent the need for this hack. Please add a comment as to considering reverting the postdata bits once that bug is fixed. > I suppose we can use ownerURI on branch and create a principal here... That'd be great. Any chance your trunk patch could make use of .ownerURI as well when .owner is missing? BTW: How portable are the serialized owners (Mac/Windows/different profiles)?
> Please add a comment as to considering reverting the postdata bits Some of those bits are needed no matter what (e.g. the setData() length changes). But yes, the base64 encoding would not be needed. > Any chance your trunk patch could make use of .ownerURI as > well when .owner is missing? That's what I meant by "create a principal here". ;) > BTW: How portable are the serialized owners (Mac/Windows/different profiles)? They're as portable as anything else we send through the binary input stream. Which means that things will work unless someone changes the serialization functions in nsPrincipal, will be portable across different endianness machines, etc.
Created attachment 281132 [details] [diff] [review] Updated branch patch Let me know if I need a different reviewer, ok?
Created attachment 281133 [details] [diff] [review] Updated trunk fix I've tested that Fx2 -> Fx2, Fx2 -> trunk, trunk -> trunk restores all work with these patches.
Comment on attachment 281133 [details] [diff] [review] Updated trunk fix r+ for the SessionStore changes. Just one detail: >+ // We can stop doing base64 encoding once our serialization into JSON >+ // is guaranteed to handle all chars in strings, including embedded >+ // nulls. JSON and toSource/uneval are two quite similar but still different serializations - and it's only the latter which fails here. What about "... once .toSource() is guaranteed ... (see bug 375639)."?
I can do that, sure. Though I wouldn't trust it to deal once that bug is fixed....
Comment on attachment 281132 [details] [diff] [review] Updated branch patch Requesting branch approval. This should be a very safe fix that fixes corner cases of session restore and about:blank subframes in most cases (basically all cases except when the parent page has a certificate principal).
Comment on attachment 281133 [details] [diff] [review] Updated trunk fix Requesting approval for regression fix. Risk is pretty low, in my opinion.
Trunk fix checked in.
Comment on attachment 281132 [details] [diff] [review] Updated branch patch approved for 184.108.40.206, a=dveditz for release-drivers
Fixed on branch
verified fixed 220.127.116.11 using Mozilla/5.0 (Windows; U; Windows NT 5.2; de; rv:18.104.22.168) Gecko/20071008 Firefox/22.214.171.124 ID:2007100816 and the steps to reproduce from this bug