Cross-origin Iframe postMessage question

[gterzian]

As part of #23637, I noticed something strange when running this test: https://github.com/servo/servo/blob/f4ff9e2eeb254a81f7b4ec9a43fe01fed2777b1a/tests/wpt/web-platform-tests/webmessaging/postMessage_MessagePorts_xorigin.sub.htm

Basically, I ran it at a commit before actually adding the transfer argument to:

servo/components/script/dom/dissimilaroriginwindow.rs

Line 138 in f4ff9e2

unsafe fn PostMessage(

Yet, from adding a few console.log, I could see that the ports were actually transferred to the iframe(leading me to proclaim cross-origin was working).

Yet, how can this have happened since DissimilarOriginWindow.PostMessage didn't support the transfer argument at that time?

Either the test is not really cross-origin, or somehow we ended-up using a local windowproxy instead of a cross-origin one?

I intend to look into this further, yet I wonder if anyone can see something obvious I might be missing...

[gterzian]

Ok so I can confirm the origin of the window and the iframe are:

window: http://web-platform.test:8000
iframe: http://www1.web-platform.test:8000

Are we treating this a cross-origin internally, or actually running those on the same event-loop?

Getting the location of the iframe window seems to return a cross-origin location, since I can't seem to be able to do anything with it.

However, I can transfer ports using PostMessage of the cross-origin window, whereas the transfer argument isn't implemented yet.

Could it be that the WindowProxy or the JS engine somehow redirects that call to a "normal" version of Window, because it can't find the method on the dissimilar version?

[gterzian]

Ok so the test ends-up using the PostMessage of a Window, not that of a DissimilarOriginWindow.

And looking at how we share event-loops, I'm pretty sure http://www1.web-platform.test:8000 and http://web-platform.test:8000 would simply run in the same event-loop.

So I'm wondering, since that test(and a lot of others) have "cross-origin" in their description yet rely on this www1 for their "cross-origin-ness", does that mean we should restrict how we share event-loops? Or am I missing something here?

From my perspective "cross-origin" always implied different event-loops, and any access to a "cross-origin" window would be via this DissimilarOriginWindow. As it turns out, we're getting much less test-coverage for that concept than I thought, because a lot of "cross-origin" wpt test will end-up being run using a plain Window. There is a different "not same site" concept that you see in some tests, but it's used pretty rarely.

For example: these two tests are meant to test the same thing but in either same- or cross-origin contexts:

• postMessage to cross-origin iframe with MessagePort array [100 ports]
• postMessage to same-origin iframe with MessagePort array [100 ports]

Yet currently, in Servo, both will be using Window and the iframes will run on the same event-loop as the parent document. There isn't a third "not-same-site" test that would be required to hit the DissimilarOriginWindow usecase in Servo...

Maybe this was expected to others, but I'm surprised. For example, there doesn't seem to a single webmessaging test that would hit DissimilarOriginWindow.PostMessage, I'll probably write one myself. I would not have noticed if it wasn't for the transfer argument to DissimilarOriginWindow.PostMessage...

cc @asajeffrey @jdm

[gterzian]

Ok so I think what we do is basically compliant with the concept of same-agent-window-objects, but, there is a spectre angle.