Cannot access App Tab iframe.document in tab from session restore after FF upgrade

VERIFIED FIXED in Firefox 8

Status

()

Core
Networking
VERIFIED FIXED
6 years ago
4 years ago

People

(Reporter: Stefan, Assigned: jesup)

Tracking

Trunk
mozilla9
Other
Other
Points:
---

Firefox Tracking Flags

(firefox8+ fixed, firefox9+ fixed)

Details

(Whiteboard: [qa!])

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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
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
(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

6 years ago
Affects FF8 as well (change made the 8 cutoff)
Assignee: nobody → rjesup
Status: NEW → ASSIGNED
tracking-firefox8: --- → ?
(Assignee)

Comment 4

6 years ago
Created attachment 555872 [details] [diff] [review]
Add another old nsIURI IID to the hack in nsBinaryStream to fix sessionrestore
(Assignee)

Comment 5

6 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 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 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+
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.
But that's definitely a separate bug.
(Assignee)

Comment 10

6 years ago
Verified with testcase
Whiteboard: [inbound]
http://hg.mozilla.org/mozilla-central/rev/e5adec25155d
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
Target Milestone: --- → mozilla9
(Reporter)

Comment 12

6 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

6 years ago
Bug 682697 Submitted

Comment 14

6 years ago
tracking this and what appears to be a regression from this fix in bug 682269
tracking-firefox8: ? → +
tracking-firefox9: ? → +
(Assignee)

Comment 15

6 years ago
Probably not Bug 682269 - Order a new laptop for laura

Probably bug 682845 (bug 682647 is almost certainly a dup of that)
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

6 years ago
Request made.
status-firefox8: --- → affected
status-firefox9: --- → affected
tracking-firefox8: + → ?
tracking-firefox9: + → ---
But you also nuked the tracking flags... :(
tracking-firefox8: ? → +
tracking-firefox9: --- → +
And I meant request approval on the _patch_, not request tracking on the bug!
(Assignee)

Updated

6 years ago
Attachment #555872 - Flags: approval-mozilla-aurora?
Attachment #555872 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Assignee)

Comment 20

6 years ago
In Aurora as https://hg.mozilla.org/releases/mozilla-aurora/rev/6f21b34b00c6
(Assignee)

Updated

6 years ago
status-firefox8: affected → fixed
status-firefox9: affected → fixed
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!]
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.