631949 - Navigations which go through document with a data URI don't respect changes to principal document's URI made by push/replaceState

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Justin Lebar (not reading bugmail)]

Attachment: Testcase

See test case.

I think this is what I was grasping at in bug 593174 comment 46, but I was having difficulty fleshing it out there.

Comment 1

[Justin Lebar (not reading bugmail)]

Attachment: Inner frame for testcase

Comment 2

[Justin Lebar (not reading bugmail)]

A working copy of these two files is at

  http://people.mozilla.org/~jlebar/test/bug631949/test1.html

Notice that no matter how many times you click the button, the referrer is always test1.html, even though the URL of the page changes every time you click.

Comment 3

[Justin Lebar (not reading bugmail)]

I think this is the same problem as in bug 622088 comment 67: When the data URI document modifies the other iframe's location, our referrer code does the following:

* Does the document's original URI match the principal's URI?  No. The original URI is a data URI, and the principal document is the outermost document.

* Therefore, let the referrer be the principal's URI.  Actually, the referrer should be the current URI of the principal document.

Comment 4

[Boris Zbarsky [:bzbarsky]]

This was a purposeful compromise when we initially did this stuff for window.location, right?

Maybe we should step back and think about how to do this right?  What state do we need to store that we aren't storing right now, if any, to do the right thing here?

Comment 5

[Justin Lebar (not reading bugmail)]

(In reply to comment #4)
> This was a purposeful compromise when we initially did this stuff for
> window.location, right?

It might have been, but I didn't do it on purpose!  :)

It seems to me that, in a lot of ways, the current URI belongs in the principal.  But that's probably conflating its purpose.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Yeah, the current URI has nothing to do with the principal; the same principal object can be shared across multiple documents which have quite different current URIs, for example.

Should we just be unconditionally using the current URI if it's not equal to the document URI, and if _those_ are equal using the principal?  Or would that regress something?

Comment 7

[Justin Lebar (not reading bugmail)]

(In reply to comment #6)
> Yeah, the current URI has nothing to do with the principal; the same principal
> object can be shared across multiple documents which have quite different
> current URIs, for example.

As I had it in my mind, one document is the primary owner of the principal.  Presumably the owner's URI is the one reflected in the principal's URI?  It's the owner's current URI that we'd want to be able to access through the principal.  (It seems like our "does the document's original URI match the principal's URI?" check is really a check for "does the document own this principal?")

Of course, if you could just get to the owning document through the principal, that would work too.  But maybe principals can outlive documents...

> Should we just be unconditionally using the current URI if it's not equal to
> the document URI, and if _those_ are equal using the principal?

What does it mean for two URIs to be equal "using the principal"?  And by "document URI", do you mean "document's current URI"?

Comment 8

[Boris Zbarsky [:bzbarsky]]

> But maybe principals can outlive documents...

Of course.  Just window.open a data: url, then close the original window.  ;)

> What does it mean for two URIs to be equal "using the principal"?

It means you misparsed my sentence.  Let me try again:

Perhaps if the document's current URI is not equal to the document's original URI we should use the document's current URI.  If they are equal, however, we should use the principal.

Is that clearer?  Will it give us the right behavior, though?

Comment 9

[Justin Lebar (not reading bugmail)]

There's still something here about a principal logically having an owner, right?

Suppose you open a data: url, change the main window's URI via replaceState, then close the main window.  If we don't store the main window's URI somewhere other than in its document, how can we get the data: URI's referrer to reflect the main window's last current URI?

> Is that clearer?  Will it give us the right behavior, though?

Yes, much.  Thanks.

But no, I don't think that fixes this problem.  You have document A with principal URI P.  It loads a data: URI into iframe F, whose principal is P.  Then you call replaceState on A, changing its URI to P'.  Now when F does a load, we'd detect that its current URI equals its original URI and send P as the referrer, but we should send P'.

Comment 10

[Boris Zbarsky [:bzbarsky]]

> There's still something here about a principal logically having an owner,
> right?

No, imo.

> how can we get the data: URI's referrer to reflect the main window's last
> current URI?

I don't think it should reflect it.

> and send P as the referrer, but we should send P'.

Why?

Comment 11

[Justin Lebar (not reading bugmail)]

(In reply to comment #10)
> > and send P as the referrer, but we should send P'.
> 
> Why?

If the main document makes a request, we'll send P' as the referrer.  So why should we send a stale URI when the document's data: URI makes a request?

Maybe you'd argue that the data: document was created before the URI changed.  But that's of course not necessary; even if it's created after the URI changes, we'll still send the original URI.

I've thought that the referrer corresponding to a data: document should be equal to the referrer corresponding to its owning document.

That seems to be what the HTML(5) spec suggests.  At least, step 2 in section 2.7 says that we start out with the document which initialized the load, then walk up its parent chain until we arrive at a document which isn't an iframe srcdoc document.  Being an iframe srcdoc document seems similar to having a data: URI, though they're obviously not the same thing.

Maybe this bug isn't important -- I'd be happy to have one less thing to worry about!  But I don't see how the current behavior is more correct.

Comment 12

[Boris Zbarsky [:bzbarsky]]

> So why should we send a stale URI when the document's data: URI makes a request?

Well, this comes down to the question of what referrer a data: URI should send.  Should it be the referrer the document that created it has now, or the one it had when the data: URI was loaded/created?  Or something else?

Without pushState this is not an issue.  With pushState, looks like it is, and the spec needs to define it if it doesn't already.

> Being an iframe srcdoc document seems similar to having a data: URI, though
> they're obviously not the same thing.

Very much not the same!

I'm not saying the current behavior is correct.  I'm saying we need to figure out what correct behavior is, get it specced, and implement it.  It sure doesn't sound like anything we've seen in this bug so far is correct behavior.

Comment 13

[Justin Lebar (not reading bugmail)]

Interestingly, it looks like our behavior with data: URIs even without pushState isn't spec'ed.

> Well, this comes down to the question of what referrer a data: URI should send.
> Should it be the referrer the document that created it has now, or the one it
> had when the data: URI was loaded/created?  Or something else?

I guess it depends on whether the "responsible party" is logically a URI or a document.  Binding to a document (and so sending its current URI as the referrer) seems most similar to what's currently spec'ed wrt srcdoc iframes.  But binding to the current URI at time of creation seems pretty reasonable to me.

What do you think?

Comment 14

[Boris Zbarsky [:bzbarsky]]

I have no idea; the only way the two can differ is pushState, and I don't have a good grasp of the semantic meaning pushState is supposed to have.... assuming there is any at all.

Comment 15

[Justin Lebar (not reading bugmail)]

Jonas, do you have an opinion?

Comment 16

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

First off, the HTML5 spec intentionally stays away from a lot of data: behavior. Implementations vary wildly on how they are treated as far as principals and I think the current sentiment is that at some point someone needs to sit down and create a comprehensive proposal for how they should be treated. So far no one has taken the time to do this.

In the meantime I think we should just do whatever we feel makes the most sense for our behavior. This will likely help compare the various behaviors once a spec is actually written.


So it seems like one of the fundamental questions here is: Is the referrer for a data:-iframe inherited from the parent document by reference or by value. I.e. should we copy what the parent document uses as referrer at the time when the contained iframe-document is created, or should we constantly use the same referrer as the parent document uses.

The more I think about it, the less I think there is a better solution. Either works for me. If someone can think of reasons for one or the other please do state them.


So with that in mind, maybe we should pick whatever we can implement the best.


If we do by-reference, I.e. if then maybe sticking the "who is the current referrer" info in the principal is the way to go.

If we do copy-when-created (which is what we currently do, right?), then adding API to nsIDocument which calculates the proper API seems useful. Possibly even backing that with a member if needed.

Comment 17

[Boris Zbarsky [:bzbarsky]]

We share principals between pages in cases other than data:.  I really don't think we want to be sticking referrers into the principal....