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

Status: RESOLVED DUPLICATE of bug 682845

(Core :: Networking, defect)

Description

[Stefan]

User Agent:  

Steps to reproduce:

1. Start Fx 2011-08-21-03-07-58-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-28-mozilla-central-debug
4. Click at the 'A'-button.


Actual results:

- no "success" string
- Error: Permission denied to access property 'document'




Expected results:

"success" message

Comment 1

[Boris Zbarsky [:bzbarsky]]

Requesting tracking for this regression; this could break session restore across browser upgrade for users...

Note that this does not appear to be a duplicate of bug 682031 given bug 682031 comment 12 and the build dates above.

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

Using the exact nightly in question (run under WinXP) I do see the problem.  

However, the IID stored sessionstore.js does not appear to be any of the IIDs used for nsIURI in the past:

760	    rv = ReadID(&iid);
(gdb) n
761	    NS_ENSURE_SUCCESS(rv, rv);
(gdb) n
781	    if (iid.Equals(oldURIiid) ||
(gdb) p/x cid
$3 = {m0 = 0x4a6212db, m1 = 0xaccb, m2 = 0x11d3, m3 = {0xb7, 0x65, 0x0, 0x60, 
    0xb0, 0xb6, 0xce, 0xcb}}
(gdb) p/x oldURIiidRIiid
No symbol "oldURIiidRIiid" in current context.
(gdb) p/x oldURIiid
$4 = {m0 = 0x7a22cc0, m1 = 0xce5, m2 = 0x11d3, m3 = {0x93, 0x31, 0x0, 0x10, 
    0x4b, 0xa0, 0xfd, 0x40}}
(gdb) p/x oldURIiid2
$5 = {m0 = 0xd6d04c36, m1 = 0xfa4, m2 = 0x4db3, m3 = {0xbe, 0x5, 0x4a, 0x18, 
    0x39, 0x71, 0x3, 0xe2}}
(gdb) p/x oldURIiid3
$6 = {m0 = 0x12120b20, m1 = 0x929, m2 = 0x40e9, m3 = {0x88, 0xcf, 0x6e, 0x8, 
    0x76, 0x6e, 0x8b, 0x23}}

Examining the nsIURI.idl file also does not show that signature in any old IID (plus the only recent changes were July 26 and Aug 15th.  The current IID is
#define NS_IURI_IID \
  {0x395fe045, 0x7d18, 0x4adb, \
    { 0xa3, 0xfd, 0xaf, 0x98, 0xc8, 0xa1, 0xaf, 0x11 }}

Continuing to investigate why (perhaps it's a dependent IID, not an nsIURI iid?)

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

Sorry, that's the cid not the iid:
(gdb) p/x iid
$8 = {m0 = 0x0, m1 = 0x0, m2 = 0x0, m3 = {0xc0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
    0x46}}

Still looking in gdb

Comment 4

[Boris Zbarsky [:bzbarsky]]

The iid in comment 3 is nsISupports.

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

Dumping current info:

I've looked at this - I don't think this is a regression from the nsIURI IID changes.  I watched the binary read point and there was no IID corresponding to any variation of nsIURI that was revved, before or after the change.

However, I found the error occurs when reading a NS_STANDARDURL_CID object (see netwerk/build/nsNetCID.h), and it happens on rv = serializable->Read(this) in nsBinaryInputStream::ReadObject() when reading the sessionstore.js file.  

I'll attach a minimal sessionstore.js file.  Take a new session, quit.  Replace sessionstore.js with this one (based on the nightly from 8/21), start browser, restore state, poof you get the error loading reported in the error page (and the test doesn't work).

// component implementing nsIStandardURL, nsIURI, nsIURL, nsISerializable,
// and nsIClassInfo.
#define NS_STANDARDURL_CLASSNAME \
    "nsStandardURL"
#define NS_STANDARDURL_CONTRACTID \
    "@mozilla.org/network/standard-url;1"
#define NS_STANDARDURL_CID                           \
{ /* de9472d0-8034-11d3-9399-00104ba0fd40 */         \
    0xde9472d0,                                      \
    0x8034,                                          \
    0x11d3,                                          \
    {0x93, 0x99, 0x00, 0x10, 0x4b, 0xa0, 0xfd, 0x40} \
}

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

Attachment: minimal sessionstore to show the problem

Comment 7

[Boris Zbarsky [:bzbarsky]]

Is the change in the serialization format of nsStandardURL from bug 665706 causing the issue here?  That landed in the comment 0 range, right?

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

Yes, that's very likely it.  Marking depends to make sure we go back and check this testcase; if the fix for that fixes this we can dup it

Comment 9

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Fix serializations of nsStandardURL broken by bug 665706

Comment 10

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 557598 [details] [diff] [review]
Fix serializations of nsStandardURL broken by bug 665706

Attached to wrong bug, meant to put on the serialization bug (which this is almost certainly a dup of)

Comment 11

[Asa Dotzler [:asa]]

tracking this in case we decided to take bug 682031 on branch

Comment 12

[Boris Zbarsky [:bzbarsky]]

This bug has nothing to do with bug 682031.  It's a regression from bug 665706.

Comment 13

[Randell Jesup [:jesup] (needinfo me)]

Bug 682845 fixed this testcase

Comment 14

[LegNeato]

Tracking the original for Fx9, removing from the flag.