1459671 - Setting document.domain doesn't enable cross-frame <form> and <a> target

Status: NEW

(Core :: DOM: Core & HTML, defect, P2)

Description

[Maxim Tsoy]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36

Steps to reproduce:

Test page: https://x.zok.pw/ff_frame_target/index.html

I have a page (see above) with a nested cross-origin iframe. Both pages set document.domain to the same value, which disables SOP.

The nested page contains a link and a form with targets pointing to a sibling empty frame.

Then I submit the form, or click the link.


Actual results:

FF sends a request in a new browser tab.


Expected results:

FF should have sent the request in the target iframe. It works like this in IE11 and Chrome 66.

Comment 1

[Andrew McCreight [:mccr8]]

Kyle, could you take a look at this? Thanks.

Comment 2

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

According to https://developer.mozilla.org/en-US/docs/Web/API/Document/domain and https://html.spec.whatwg.org/multipage/origin.html#relaxing-the-same-origin-restriction this should work, and I've successfully repro'd the STR in Comment 0. 

Kinda surprised this isn't covered in WPTs.

Comment 3

[Maxim Tsoy]

Shouldn't this be set to "CONFIRMED"?

Comment 4

[Andrew McCreight [:mccr8]]

(In reply to Maxim Tsoy from comment #3)
> Shouldn't this be set to "CONFIRMED"?

Sure, though in practice there is little difference between ASSIGNED, NEW and UNCONFIRMED.

Comment 5

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

Just correcting myself from Comment 2, this (and other possible document.domain setting failures) are covered in WPTs (testing/web-platform/tests/html/browsers/origin/relaxing-the-same-origin-restriction/*), we just have most of the tests there marked as failing, which might be why this is missing. Gonna try to figure out why we're failing those.

Comment 6

[Boris Zbarsky [:bzbarsky]]

The spec for this is at https://html.spec.whatwg.org/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name

In step 6, we can use a browsing context with the given name if our browsing context is "familiar" with it, in the sense of https://html.spec.whatwg.org/multipage/browsers.html#familiar-with

That can return true in the following cases:

* The origins of the active documents are "same" in the sense of <https://html.spec.whatwg.org/multipage/origin.html#same-origin>. In this case they are not, because this check does NOT consider document.domain (it's a "same" check, not a "same origin-domain" check).

* A is a nested browsing context within toplevel browsing context B.  In this case A and B are sibling frames, so this tests false.

* B is was opened via "window.open" and some other conditions apply.  Not true in this case.

* B is a subframe which has an ancestor which has an active document that is same origin as the active document of A.  Again, this check ignores document.domain.

So per spec, we are doing the right thing here.  That said, no one else is following the spec, apparently.  :(

Last I checked, the spec aimed to restrict use of "same origin-domain" to cases that are actually needed for web compat; from a security point of view it sure would be good if the other browsers just got their act together and followed the spec.

Comment 7

[Anne (:annevk)]

Filed https://github.com/whatwg/html/issues/3747 to see if there's interest in converging on Firefox's behavior.

Kyle, this isn't tested yet in that directory. Not sure about other directories though.

Comment 8

[Maxim Tsoy]

Thank you guys! Indeed, it looks like it makes sense to continue the discussion in the spec ticket.
Boris, could you elaborate a bit (or provide some links) on the "cases that are actually needed for web compat"? I don't quite understand what that means.
We are currently relying on this behaviour in Surfly. We control all 3 frames but we need to be able to target sibling frames from the others. If this ticket doesn't come through we will have to emulate the form submission from the parent window which is a lot of work.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

It is? Copy the form values to the sibling you want to target and submit?

Comment 10

[Maxim Tsoy]

(In reply to Olli Pettay [:smaug] from comment #9)
> It is? Copy the form values to the sibling you want to target and submit?

In our case it looks like it is, unfortunately. From the top of my head I expect some problems in transferring file inputs and supporting the <base> tag. Besides, we'd have to carefully trap all <form> attribute changes as well as all form submission triggers and onsubmit handlers.
At this moment we get that all for free just by changing the target attribute in onsubmit.

Comment 11

[Boris Zbarsky [:bzbarsky]]

> could you elaborate a bit (or provide some links) on the "cases that are actually needed for web compat"? 

It basically comes down to "use checks that ignored document.domain in all the cases except the ones where browsers say they're not willing to ship it because it breaks too many sites".  This was not one of those cases; this is the first report we've ever gotten about anyone encountering a problem with the currently specced behavior.

Note that browsers keep trying to come up with ways to deprecate and kill document.domain.  There are all sorts of proposals for upcoming APIs to have them not work in pages that set it.

I agree that it does seem weird in this case that you would be able to affect absolutely anything about the target frame but can't navigate it by name.  If the long-term plan were not to remove document.domain altogether (which means this entire design would need rethinking, and we would probably want to provide some APIs for achieving it without document.domain) I would say we should definitely change "familiar with" to do "same origin-domain" checks...

Comment 12

[Maxim Tsoy]

Is there any chance to fix this behaviour in Firefox? Sure, document.domain is deprecated, but it seems to me that it will not go anywhere until there's another API to replace it. And until then, it is a compatibility bug of Firefox, which (in our case) is nearly impossible to work around.

Comment 13

[Boris Zbarsky [:bzbarsky]]

There is generally an API to replace document.domain: postMessage.

As far as this bug, changes here are blocked on the spec being updated and/or someone figuring out exactly what other browsers are doing here (which is probably a prereq for the spec being updated). Just removing the same-origin restriction on targeting navigations is definitely not what they do, so the question at the very least is whether they just do same-origin-domain checks or something else.

That said, I'm a little surprised that there isn't an existing way to do a "navigate to this FormData" kind of thing, at least not if one is trying to do a POST... Anne, have there been proposals for such an API?

Comment 14

[Anne (:annevk)]

It would be somewhat easy to polyfill now that there's a formdata event on form element submission, but there's no dedicated API, no. We probably should look into some APIs around navigating (and downloading) at some point, but it'd be nice if navigation was less of a mess first.