Closed
Bug 682031
Opened 13 years ago
Closed 13 years ago
Cannot access App Tab iframe.document in tab from session restore after FF upgrade
Categories
(Core :: Networking, defect)
Tracking
()
VERIFIED
FIXED
mozilla9
People
(Reporter: kdevel, Assigned: jesup)
References
Details
(Whiteboard: [qa!])
Attachments
(1 file)
1.24 KB,
patch
|
dholbert
:
review+
bzbarsky
:
review+
johnath
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
User Agent: Steps to reproduce: 1. Start Fx 2011-08-14-03-07-49-mozilla-central with new profile. 2. Open Testcase from Bug 662242 https://bugzilla.mozilla.org/attachment.cgi?id=537650 Pin tab as app tab. 3. Close Fx. 4. Start Fx 2011-08-21-03-07-58-mozilla-central. 4. Click at the 'A'-button. Actual results: - no "success" string - Error: Permission denied to access property 'document' Source File: https://bug662242.bugzilla.mozilla.org/attachment.cgi?id=537517 Line: 10 Expected results: "success" message
Comment 1•13 years ago
|
||
Stefan, thanks for filing this. I would guess that this broke when bug 677260 change the nsIURI iid, because nsPrincipal writes out the IID as part of the data it writes. There are existing hacks in nsBinaryInputStream::ReadObject to deal with that; we need to add another one. We should consider changing nsPrincipal to write the URIs out as nsISupports..... Randell, this is a fx9 issue only, right, or did bug 677260 make fx8 aurora?
Blocks: 677260
Status: UNCONFIRMED → NEW
tracking-firefox9:
--- → ?
Component: Networking: Cache → Networking
Ever confirmed: true
QA Contact: networking.cache → networking
Comment 2•13 years ago
|
||
(In reply to Boris Zbarsky (:bz) from comment #1) > Stefan, thanks for filing this. I would guess that this broke when bug > 677260 change the nsIURI iid, because nsPrincipal writes out the IID as part > of the data it writes. Ah yes -- sadly, this breaks (read: needs an addition to the existing hackaround) whenever the nsIURI iid changes. We really should change nsPrincipal as bz suggests. (That's bug 662693) See comment about this in the nsIURI idl file: http://mxr.mozilla.org/mozilla-central/source/netwerk/base/public/nsIURI.idl#98
Assignee | ||
Comment 3•13 years ago
|
||
Affects FF8 as well (change made the 8 cutoff)
Assignee | ||
Comment 4•13 years ago
|
||
Assignee | ||
Comment 5•13 years ago
|
||
Comment on attachment 555872 [details] [diff] [review] Add another old nsIURI IID to the hack in nsBinaryStream to fix sessionrestore full disclosure: I've built and run it, but I haven't tested the sequence given yet -- will do so tonight.
Attachment #555872 -
Flags: review?(dholbert)
Comment 6•13 years ago
|
||
Comment on attachment 555872 [details] [diff] [review] Add another old nsIURI IID to the hack in nsBinaryStream to fix sessionrestore Looks good to me (though I hope this is the last extension of this hack that we'll need... you or I or someone should really fix bug 662693 before the next time we tweak nsIURI. :)) I think you'll need sign-off from someone with more xpcom know-how, too. (I've written very few patches for /xpcom, and I don't believe I've ever reviewed any patches there). Flagging additional-r?bz. We should get this into Aurora as soon as we can.
Attachment #555872 -
Flags: review?(dholbert)
Attachment #555872 -
Flags: review?(bzbarsky)
Attachment #555872 -
Flags: review+
Comment 7•13 years ago
|
||
Comment on attachment 555872 [details] [diff] [review] Add another old nsIURI IID to the hack in nsBinaryStream to fix sessionrestore r=me
Attachment #555872 -
Flags: review?(bzbarsky) → review+
Comment 8•13 years ago
|
||
I'm actually tempted to say that we should remove the function signatures that serialize any IID other than nsISupports.... and then not save the iid at all.
Comment 9•13 years ago
|
||
But that's definitely a separate bug.
Comment 11•13 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/e5adec25155d
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
Target Milestone: --- → mozilla9
Reporter | ||
Comment 12•13 years ago
|
||
(In reply to Randell Jesup [:jesup] from comment #10) > Verified with testcase Sure that you verified with the correct versions? I just encountered the bug when starting a Fx built from current revision 6c8a909977d3 on a profile which was written with a revision 3d615a56ad46 (of 2011-08-17).
Reporter | ||
Comment 13•13 years ago
|
||
Bug 682697 Submitted
Comment 14•13 years ago
|
||
tracking this and what appears to be a regression from this fix in bug 682269
Assignee | ||
Comment 15•13 years ago
|
||
Probably not Bug 682269 - Order a new laptop for laura Probably bug 682845 (bug 682647 is almost certainly a dup of that)
Comment 16•13 years ago
|
||
There are no known regressions from this fix. And this fix does need to land on aurora. Randell, please request approval accordingly.
Assignee | ||
Comment 17•13 years ago
|
||
Request made.
Comment 19•13 years ago
|
||
And I meant request approval on the _patch_, not request tracking on the bug!
Assignee | ||
Updated•13 years ago
|
Attachment #555872 -
Flags: approval-mozilla-aurora?
Updated•13 years ago
|
Attachment #555872 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Assignee | ||
Comment 20•13 years ago
|
||
In Aurora as https://hg.mozilla.org/releases/mozilla-aurora/rev/6f21b34b00c6
Assignee | ||
Updated•13 years ago
|
Comment 21•13 years ago
|
||
Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20100101 Firefox/8.0 Mozilla/5.0 (Windows NT 6.1; rv:9.0a2) Gecko/20111004 Firefox/9.0a2 Mozilla/5.0 (Windows NT 6.1; rv:10.0a1) Gecko/20111004 Firefox/10.0a1 Mozilla/5.0 (Windows NT 5.1; rv:10.0a1) Gecko/20111004 Firefox/10.0a1 Mozilla/5.0 (Windows NT 5.1; rv:9.0a2) Gecko/20111004 Firefox/9.0a2 Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0 Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0 Mozilla/5.0 (X11; Linux x86_64; rv:9.0a2) Gecko/20111005 Firefox/9.0a2 Mozilla/5.0 (X11; Linux x86_64; rv:10.0a1) Gecko/20111004 Firefox/10.0a1 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20100101 Firefox/8.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0a2) Gecko/20110921 Firefox/8.0a2 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0a1) Gecko/20110919 Firefox/9.0a1 Verified on Mac OS 10.6, Ubuntu 11.04, Windows Xp and 7 using the steps in comment 0. I have upgraded from Firefox 7.0.1 to Firefox 8, from Firefox 8 to 9 and from 9 to 10. The success string was displayed as expected.
Status: RESOLVED → VERIFIED
Whiteboard: [qa!]
Comment 22•13 years ago
|
||
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0a2) Gecko/20111006 Firefox/9.0a2 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a1) Gecko/20111006 Firefox/10.0a1 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20100101 Firefox/8.0 These are the correct build ids on Mac OS 10.6.
You need to log in
before you can comment on or make changes to this bug.
Description
•