Fix #536: Abort document.open if origins mismatch

[jeisinger]

This matches the implementation of Firefox, and will automatically
resolve the issue that we use the document's origin for initializing the
realm but the responsible document's url for setting the url: After this
change, the document's origin and the responsible document's origin will
be equal.

[jeisinger]

@bzbarsky @foolip wdyt?

[zcorpan]

s/an/a/

[jeisinger]

done

[jeisinger]

note that Blink actually makes the doc's origin and alias of the responsible doc's origin, but FF doesn't.

[foolip]

So the style conventions for this spec are a bit special, but when an <li> (or <dd> etc.) has only a single <p> child, they flow together, as in the <li> right above here. No clang-format for this, so we get to have fun in review :)

[foolip]

The change itself LGTM assuming this is precisely what Gecko does (let's let @bzbarsky confirm) but is this whole fix for #536? Does the question about which document to copy from become moot because the two documents involved are guaranteed to be the same, or...?

[jeisinger]

kinda - at least that's what FF implements as far as I can tell, and it would solve my specific problem (define what origin the resulting document should have)

[foolip]

That's good! Can you tell if https://html.spec.whatwg.org/multipage/webappapis.html#set-up-a-browsing-context-environment-settings-object is till wrong? If this merely hides the issue in this instance, we need a separate issue to figure that out.

[jeisinger]

it's a bit difficult to tell for me, as Blink's implementation of document.open() doesn't exactly align with the spec :-/

Maybe @bzbarsky can tell whether it's still not aligned with FF's implementation?

[annevk]

So I think the way this is handled in Firefox is through a generic origin check at the IDL layer that applies to everything, not just document.open(): https://github.com/annevk/html-cross-origin-objects.

[jeisinger]

well, at least in the source, there's an explicit check: http://mxr.mozilla.org/mozilla-central/source/dom/html/nsHTMLDocument.cpp#1497

[annevk]

Interesting, I'll defer to @bzbarsky and @bholley then.

[bzbarsky]

There are two separate checks in Firefox.

The first check, at the IDL layer, ensures that the effective script origin of the global of the Realm of the open function matches the effective script origin of the HTMLDocument object. This check applies in pretty much all cases (except some things on Window and Location). This is the "perform a security check" bit from the IDL spec.

For document.open specifically, there is an additional check, as cited by @jeisinger, which compares the origin (not the effective script origin) of the entry document to the origin of the document used as this for the open call. If this check fails, Firefox throws a SecurityError DOMException.

In web-facing terms, the main effect of this in Firefox is that if two sites start out not-same-origin and then set document.domain to the same thing they can touch each other's objects but can't call document.open on each other. I think that's OK, personally.

The diff here looks good to me.

[jeisinger]

updated the formatting

[annevk]

Committed as 05599ab. Thank you!

[annevk]

(I had to change the formatting a bit more, but no big deal.)

[Ms2ger]

@jeisinger, feel like writing a test for this case?

[jeisinger]

I'll give it a try

On Fri, Jan 29, 2016, 2:22 PM Ms2ger [email protected] wrote:

@jeisinger https://github.com/jeisinger, feel like writing a test for
this case?

—
Reply to this email directly or view it on GitHub
#583 (comment).