-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplifying incument realm definition to match Blink? #2535
Comments
Oh, right. Re-reading #1542 this only works because Chrome has the not-per-spec implementation of creating new function wrappers for every cross-window method access, not just cross-origin ones. Since I'm pretty sure we don't want to copy that, this issue is probably moot, as we'll still need a relatively-complicated incumbent definition to take care of at least postMessage (again see #1542). I'll leave this open in case @bzbarsky and @bholley want to comment on the prospect of creating function wrappers for every cross-window method access, but I'm now less hopeful. |
Does Chrome create new function wrappers for same-origin cross-window access for all properties, or just some properties? |
Chrome currently creates new function wrappers for cross-origin accessible DOM operations. |
@yuki3 I think it would help if you could clarify that a bit more. In particular, neither DOM operation nor DOM attribute (IDL attribute, therefore JavaScript getter/setter?) is a defined term. Also, do you mean that it creates wrappers for those even when accessed same-origin? |
Sorry, I meant that Chrome creates new function wrappers for same-origin cross-window access for cross-origin accessible IDL operations. When you access a cross-origin accessible IDL operation, Chrome returns a function wrapper created in the Current realm. Chrome creates a function wrapper per realm and re-uses it in the same realm. |
So in other words, otherWindow.postMessage and otherWindow.alert have different behavior in Chrome, in the case when otherWindow is same-origin. |
Yes, concretely in that What do you think of that? Horrible hack? Innovative solution? My assumption is that you'd prefer to stay the course on tracking and defining incumbent, but I realized we never discussed this idea seriously, besides calling it a Chrome bug. |
So... Some testing shows that the above description of Chrome's behavior is at best incomplete. For example, if either page assigns to postMessage on the window in question, after that point they see the same value. So concretely, if I have this page:
that logs Same thing if the subframe just does The good news is that at least this means the MOP invariants are not violated. The bad news is that this behavior is rather surprising... |
Let's not do this; closing. |
Blink, in particular @yuki3, is thinking about implementing the incumbent concept in Q2. However, I wanted to check in first to see if maybe we should change the spec to use what Blink currently does, in case it is simpler. /cc @bzbarsky @bholley
There
Some discussion has already taken place in the margins of a Blink quarter-planning doc, but let's move it here. There @yuki3 says:
I believe this "function object created in the current realm" business matches the spec already, as of last year's work on cross-origin properties. So the question is about using f's realm (i.e., the current realm at the time the algorithm is running) vs. the incumbent realm.
Going through the examples in the spec in the linked section, as far as I can tell this means:
window
for the postMessage.bind example, via a much simpler path than the spec.a
's environment settings object for the "final even more convoluted example", via a much simpler path than the spec.I'm not sure what other test cases we might want to involve, but this does seem pretty nice and simple. @bzbarsky, can you think of any downsides to switching to Blink's version? Concretely, I guess that would mean replacing all references to "incumbent settings object" with "current settings object"---which is kind of where we were heading anyway, via #1430.
(This seems too easy, so I'm probably missing something...)
There's also at least some chance (untested) that Blink and WebKit still match, which would imply a shorter path to interop via aligning with Blink.
The text was updated successfully, but these errors were encountered: