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

Status: VERIFIED FIXED

(Core :: Networking: Cache, defect)

Description

[Stefan]

User-Agent:       
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110605 Firefox/7.0a1

After a software upgrade an active app-tab application can no longer access the document-property of an (empty) iframe.

Only those upgrades are affected, which have old version less than and target version greather equals revision e9c7616c4f72.

http://hg.mozilla.org/mozilla-central/rev/e9c7616c4f72
"Bug 308590 patch 2: Move GetRef/SetRef from nsIURL to nsIURI. r=bz sr=biesi"

Reproducible: Always

Steps to Reproduce:
STR will be handed in later.

Actual Results:  
"Error: Permission denied to access property 'document'"

Expected Results:  
Allow access to property 'document' even after a software upgrade.

Comment 1

[Stefan]

Attachment: Testcase

Comment 2

[Stefan]

Steps to Reproduce:

1. start FF 4.0.1 (or any other version > 4.0.1 and < rev.e9c7616c4f72)
2. open Testcase url, pin tab as app tab
3. close FF
4. perform update to FF >= rev.e9c7616c4f72, start new FF
5. 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 Result:
"success" message

Comment 3

[u279076]

This does not seem to have any correlation whatsoever to Session Store. Moving into Firefox::General until a more appropriate component can be found.

Comment 4

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Does this only fail in the upgrade case? This is working just fine for me when restarting latest Nightly.

Comment 5

[Stefan]

(In reply to comment #4)
Yes. You need to perform an upgrade from and to the abovementioned versions in order to reproduce. (Downgrade works, too).

Comment 6

[Stefan]

Attachment: validated Testcase

Comment 7

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

dholbert - you wrote the patch being blamed... any ideas?

Comment 8

[Daniel Holbert [:dholbert]]

I'm guessing that when we're in Firefox 4.0, we serialize URIs in the document (to disk cache), and then when we deserialize them, we get an equality failure when comparing an deserialized URI from Firefox 4 vs. a freshly-parsed URI from Firefox 5.

And as a result of that URI equality failure, we prevent modifications to the iframe, as a security provision.  ("Error: Permission denied to access property 'document'")

Or something like that.  I can look in more detail in a bit.

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to comment #8)
> comparing an deserialized URI from Firefox 4 vs. a
> freshly-parsed URI from Firefox 5.

sorry, s/Firefox 5/Trunk or Aurora/. (Bug 308590's patches aren't in Firefox 5, though they are in Trunk & Aurora)

Comment 10

[Jason Duell]

cc-ing some HTTP cache folks.  From IRC chat seems like a likely solution is to bump nsDiskCache::kCurrentVersion.  Which is a heavy hammer--it'll blow away all user's disk cache when they upgrade :( --but perhaps the only way to fix.

Comment 11

[Jason Duell]

Unless we can add support for deserializing v4 URIs into v5 ones?  And/or making them equal to "freshly parsed" v5 uri (not sure of the details here).

Comment 12

[Daniel Holbert [:dholbert]]

> 4. perform update to FF >= rev.e9c7616c4f72,
FWIW, that cset didn't actually change any functionality, really -- it effectively added a (unused) method on nsIURI, and revved the uuids on nsIURI and nsIURL.

Maybe revving the uuids is what broken this?

Comment 13

[Boris Zbarsky [:bzbarsky]]

I would expect that revving the CID and serialization code of nsSimpleURI is a more likely culprit, but that's a different changeset.

In fact, that patch would have made principal deserialization fail, which would have made the iframe in the attached testcase have a different principal from the main frame.

There's no good workaround here.  I thought about the issue when reviewing the nsSimpleURI changes, but there was just no way to keep the serialization compatible-enough because the format is so rigid.  And the CID change, of course, kills the deserialization dead...

Comment 14

[Boris Zbarsky [:bzbarsky]]

Note that I suspect that this is wholly unrelated to the HTTP cache.

Comment 15

[:Gavin Sharp [email: [e-mail]]]

Where does the URI serialization come into play here? I didn't think sessionstore serialized URIs (AFAIK it just uses .spec).

Comment 16

[Boris Zbarsky [:bzbarsky]]

It serializes principals, I thought, and principal serialization serializes the URI of the principal...

Comment 17

[Daniel Holbert [:dholbert]]

(In reply to comment #14)
> Note that I suspect that this is wholly unrelated to the HTTP cache.

Hrm... a local nsDiskCache::kCurrentVersion-incrementing patch says that you're right about that.  (Incrementing the cache version doesn't seem to fix this.)

I'd initially thought this was cache-related because shift-reloading the app-tab in a mozilla-central build does seem to fix the problem.  But I guess that assumption was off-base...

Comment 18

[:Gavin Sharp [email: [e-mail]]]

zpao points to http://hg.mozilla.org/mozilla-central/annotate/f4321cdcef37/browser/components/sessionstore/src/nsSessionStore.js#l1771 as sessionstore code that could be influenced by nsIURI serialization differences.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Yes, see comment 16.

I'm sort of sad we're still using the quick hack we put in place to serialize principals/URIs via nsISerializable.  It's really not designed for changes where you want to make sure you preserve information: the original design is for a cache, where just blowing the cache away when the object layout changes is fine...

Comment 20

[Boris Zbarsky [:bzbarsky]]

Thinking about this a bit more...  For the specific case of _upgrading_, we could perhaps make this work with some hackery.  Create a new class called nsCompatSimpleURI that has the same CID as the old nsSimpleURI CID, have it inherit from nsSimpleURI, and have it override the classinfo bits to return the different CID and override Read() to do what the old nsSimpleURI::Read did plus some sane-ish init of the new members.

For downgrading, that won't fly, though.

Comment 21

[Daniel Holbert [:dholbert]]

(In reply to comment #12)
> > 4. perform update to FF >= rev.e9c7616c4f72,
> FWIW, that cset didn't actually change any functionality, really
[...]
> Maybe revving the uuids is what broken this?

I verified that this quoted chunk is correct (with s/broken this/broke this/ :))  That is -- the interface UUID changes are what trigger the bustage.

Specifically:
 (A) A targeted build at rev e9c7616c4f72 is broken.
 (B) The same build with the UUIDs reverted is *not* broken.

Comment 22

[Daniel Holbert [:dholbert]]

(In reply to comment #20)
> Thinking about this a bit more...  For the specific case of _upgrading_, we
> could perhaps make this work with some hackery.  Create a new class called
> nsCompatSimpleURI that has the same CID as the old nsSimpleURI CID

For the purpose of fixing this bug's specific testcase, the above fix isn't actually required -- the nsIURI in that we fail to deserialize here is:
  https://bug662242.bugzilla.mozilla.org/attachment.cgi?id=537650
...which is a nsStandardURL, not a nsSimpleURI. (and the CID of nsStandardURL has not changed.)

However, I think we do need bz's proposed nsCompatSimpleURI for e.g. data URIs or "about:" URI app-tabs to deserialize correctly.

Comment 23

[Boris Zbarsky [:bzbarsky]]

The only time we need URI deserialization is for principals, so I suspect it's not a big deal.

Comment 24

[Daniel Holbert [:dholbert]]

Attachment: patch 1: iid switcheroo in nsBinaryInputStream::ReadObject.

This patch is sufficient to fix this bug's testcase.  (though as noted in previous comment, we'll need something more to fix an equivalent-but-non-URL testcase)

Comment 25

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 537895 [details] [diff] [review]
patch 1: iid switcheroo in nsBinaryInputStream::ReadObject.

Please add a comment in nsIURI.idl pointing to this code?  r=me with that.

Comment 26

[Daniel Holbert [:dholbert]]

(In reply to comment #22)
> However, I think we do need bz's proposed nsCompatSimpleURI for e.g. data
> URIs or "about:" URI app-tabs to deserialize correctly.

bz points out on IRC (clarifying comment 23) that data URIs actually get a nsNullPrincipal, not some principal involving a nsSimpleURI, so they won't be bitten by this.

"about:" URIs vary on what sort of principal they get, and it's possible that some addon could create an about: URI that would hit this bug when restored from sessionstore.  (though this would only be a problem if the about: URI in question contained iframes, and those iframes use the same principal as the about: page itself)

This case seems somewhat contrived/unlikely... and even if it happens, there are of course easy workarounds that permanently fix the issue (shift-reload, or focus-urlbar-and-hit-enter, or reopen the URI in a new tab).  So I tend to think it's not worth adding the nsCompatSimpleURI workaround to fix this low-likelihood edge case.

Comment 27

[Daniel Holbert [:dholbert]]

Attachment: patch 1 v2: IID switcheroo in nsBinaryInputStream::ReadObject

Added a comment to nsIURI, and also tweaked the added code chunk to use NS_IURI_IID in place of the hardcoded current-IID.

Re-requesting review to be sure the comment is ok & that you're ok with the NS_IURI_IID code-change.

Comment 28

[Daniel Holbert [:dholbert]]

Filed bug 662693 on serializing nsPrincipal's member-nsIURI-vars as nsISupports instead of as nsIURI, to prevent future instances of this bug. (bz, correct me if I'm mistaken about that)

Comment 29

[Daniel Holbert [:dholbert]]

Attachment: patch 1 v2a: IID switcheroo in nsBinaryInputStream::ReadObject

Per gavin's note in IRC, I'm tweaking the nsIURI comment to blame nsPrincipal URI-serialization (and bug 662693) rather than sessionstore.

Comment 30

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 537919 [details] [diff] [review]
patch 1 v2a: IID switcheroo in nsBinaryInputStream::ReadObject

You don't need the newURIiid temporary.  r=me with that.

Comment 31

[Daniel Holbert [:dholbert]]

(In reply to comment #30)
> You don't need the newURIiid temporary.

That's what I thought at first too, but it won't compile if I remove the temporary var.

NS_IURI_IID is a bracketed list like { 0xabc { 0x123 } }, which gets treated specially.  So the following three simplified lines all cause compile errors:
> iid = NS_IURI_IID;
> iid = nsIID(NS_IURI_IID);
> const nsIID newURIiid(NS_IURI_IID);
...since both nsID::operator= and nsID::nsID() reject bracketed lists as an input.

AFAICT, only this will compile:
> const nsIID newURIiid = NS_IURI_IID;

Correct me if I'm missing something, though. :)

Comment 32

[Boris Zbarsky [:bzbarsky]]

Ah, ok.  Never mind that comment, then!

Comment 33

[Daniel Holbert [:dholbert]]

Fixed on trunk:
http://hg.mozilla.org/mozilla-central/rev/72400ce3811c

Needs fixing on aurora; requesting approval in a second.

Comment 34

[Daniel Holbert [:dholbert]]

Overview of patch, for approval purposes:
 - Reward: fixes possible issues with restoring a pre-Firefox6 session after upgrading to Firefox6.
 - Risk: Specifically checks for the old nsIURI IID, when de-serializing an object, and replaces it with the new one.

The nsStandardURL CID (and structure) hasn't changed, so we'll still be creating nsStandardURL instances, and deserializing them.  It's just that one of the interfaces (the one we care about QI'ing the created object to in this case) has had its IID revved, and we need to QI to the *new* interface ID for the deserialization to succeed.

This is a semi-ugly hack, but it's very targeted and hopefully avoidable in the future once bug 662693 is fixed.  (and it's kinda necessary for sessionstore to work through an upgrades)

Comment 35

[Daniel Holbert [:dholbert]]

(In reply to comment #34)
>  - Risk: Specifically checks for the old nsIURI IID, when de-serializing an
> object, and replaces it with the new one.

(sorry, that's more of a summary than a risk level.  I meant "risk: low, imho". :))

Comment 36

[Daniel Holbert [:dholbert]]

Sorry, lost track of this.

Landed on aurora: http://hg.mozilla.org/releases/mozilla-aurora/rev/903365ff5efa

Comment 37

[Vlad [QA]]

Setting resolution to Verified Fixed on Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20100101 Firefox/6.0 beta5

Comment 38

[Stefan]

Regression. In step #1 take 2011-08-01-03-09-16-mozilla-central
amd in         step #4 take 2011-08-21-03-07-58-mozilla-central

Comment 39

[Boris Zbarsky [:bzbarsky]]

I have no idea what comment 38 is about, but it should be in some other (possibly new) bug.

Comment 40

[u279076]

@Stefan please file a new bug describing the issue you are seeing with that regression range. Thanks

Comment 41

[Stefan]

Bug 682031 Submitted

Comment 42

[u279076]

@Stefan no need to reopen this bug once you file a new one. Thanks

Comment 43

[Stefan]

@Anthony Hughes the status changed automatically when I submitted comment #41.

Comment 44

[Daniel Holbert [:dholbert]]

(yup that's Bugzilla being silly, not your fault)