No way to resolve a Promise with a cross domain WindowProxy

[esprehn]

Since resolving a promise looks for a thenable and accessing the then property on a cross domain WindowProxy throws you can't do something like:

const loadFrame = (src) => new Promise((resolve) => {
  frame.src = src;
  frame.onload = () => resolve(frame.contentWindow);
});

Perhaps cross domain WindowProxy objects should allow accessing then and have it always be undefined?

[annevk]

This is technically an issue with whatwg/html, but we can discuss it here. I don't care strongly.

If this also needs to work for cross-origin Location objects it would be simplest to change step 1 of https://html.spec.whatwg.org/#crossorigingetownpropertyhelper-(-o,-p-) and step 3 of https://html.spec.whatwg.org/#crossoriginownpropertykeys-(-o-): add "then" to the list of those three symbols.

cc @bzbarsky @cdumez @domenic

[bzbarsky]

We probably could do that. @bholley may have opinions on whether it's OK from his pov security-wise.

I just double-checked the interaction with subframes named "then", and I think it should be ok, since at https://html.spec.whatwg.org/#windowproxy-getownproperty step 5 the value would be undefined, then at step 6 we would find the named subframe, but it's not callable, so would not affect the Promise behavior.

[esprehn]

(Sorry about filing in the wrong repo @annevk my bad :)

@mikewest

[bholley]

Note: I'm on leave, so probably can't formulate a definitive answer here in a timeframe that would be useful. That said, it seems fine at first glance, and so I'm happy deferring to Boris.

[domenic]

This seems like a generally good idea to me; basically treating it the same as toStringTag/hasInstance/isConcatSpreadable. I've forgotten why those need to return a property with value undefined, instead of just saying there's no such property, but that's separate I guess.

[annevk]

@domenic I think that's for the same reason. So obvious operations you might apply to objects don't end up throwing. (Although those might also have been driven by web compatibility.)

[domenic]

No, I mean, just omitting the property would also work (i.e. avoid the throwing), so I don't remember why we made them explicitly present as undefined. Shrug

[annevk]

I don't understand, getting a property that does not exist will throw on a cross-origin object. E.g., try <iframe src=data:, onload=w(this.contentWindow.x)></iframe> in LDV.

[domenic]

Right, because we specced it to. We could spec that for these 3-4 properties, it doesn't exist and doesn't throw. Instead we specced that it does exist and doesn't throw.

[annevk]

Ah, https://lists.w3.org/Archives/Public/public-script-coord/2015JulSep/0032.html and https://bugs.chromium.org/p/chromium/issues/detail?id=532469 suggest your alternative might not have been considered.

[domenic]

Got it. Oh well, I don't think it's better in any way that's worth the churn. Just glad to have my curiousity satisfied :). Sorry for derailing the thread. Back on topic...

@yuki3 @cdumez, are you up for adding then to the list of undefined cross-origin properties? Currently it contains @@toStringTag, @@hasInstance, and @@isConcatSpreadable.

[yuki3]

Blink's implementation is still far from the ideal state, but I can implement something so that crossOriginWindow.then returns undefined. However, I have a concern.

If we add then to HTML 7.2.3.3 CrossOriginGetOwnPropertyHelper, then then has a priority over 7.2.3.1 CrossOriginProperties, right? IIUC, it shadows a child browsing context with the name "then".

Should we deprioritize then? @@toStringTag, etc. are probably okay because they're symbols.

[yuki3]

Oops, maybe I'm wrong. We'd like to intentionally shadow then even though it would break the backward compatibility, right? Just in case, I'd like to confirm it before implementing. Is it okay?

[annevk]

I'm not sure if that's what we want. It's easy enough to move step 1 of CrossOriginGetOwnPropertyHelper down and it would be more consistent with how a same-origin window behaves.

The potential for conflict would also complicate CrossOriginOwnPropertyKeys somewhat as we don't want to return duplicate keys there. We'd only want to append "then" if it's not there already.

[bzbarsky]

then then has a priority over 7.2.3.1 CrossOriginProperties, right? IIUC, it shadows a child browsing context with the name "then".

Oh, good catch. I got confused between undefined-the-value and undefined-the-descriptor when looking at https://html.spec.whatwg.org/multipage/window-object.html#windowproxy-getownproperty

I agree that this is not desirable. If there's a named subframe called "then", we should expose it in the usual way. It won't affect the Promise behavior, per #536 (comment)

[yuki3]

I see. I understand that we wouldn't like to shadow "then". I agree that it's reasonable. I'll implement it in Blink accordingly.

[annevk]

I created a PR that should match the discussion above. Anyone keen on writing tests?

[yuki3]

Just FYI, I landed a patch in Blink.
https://chromium-review.googlesource.com/c/chromium/src/+/779319

(I know that it's imperfect from a lot of point of views, and wouldn't pass the coming WPTs. But crossOriginObject.then returns undefined at least.)

[bzbarsky]

I wrote some tests in https://bug1435596.bmoattachments.org/attachment.cgi?id=8949101

Chrome fails most of the relevant wpt already, unfortunately, which makes behavior around this stuff really hard to test there.