Remove frameType, maybe add ancestorOrigins

[annevk]

Frame type does not address the use case of e.g., an embedded youtube.com showing fallback content. (Where youtube.com embedded in youtube.com should not show such a thing.)

[jungkees]

F2F: Spec ancestorOrigins and remove frameType for now. We can get it back if it's really required in the future.

[jungkees]

Just to check if the decision still holds. Is it still okay to remove Client.frameType?

[jakearchibald]

F2F: Adding ancestorOrigins if fine as long as you can already get this information.

frameType is still useful for "auxiliary", which you can't determine from ancestorOrigins.

[annevk]

When do you want to check auxiliary? Should it be auxiliary when noopener is set?

[jakearchibald]

Pre F2F notes: come up with an answer to @annevk's question

[jakearchibald]

F2F:

• We don't have solid use-cases for frameType right now, we should remove it and add it back if/when we get better data
• Keep ancestorOrigins, but it's only needed on WindowClient

[wanderview]

Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1290936

[jungkees]

@annevk, I'm planning to factor the steps of location.ancestorOrigins out as an algorithm that both location.ancestorOrigins and WindowClient.ancestorOrigins can invoke (taking an environment settings object as an argument.)

Currently, location.ancestorOrigins's step 1 throws "SecurityError" if the relevant document's origin is not the same as entry settings object's origin. I don't think this would be meaningful for WindowClient.ancestorOrigins where the entry settings object's origin will always be the same as the client's origin. I'm not sure what the purpose of this security check in the first place.

In case we should retain this entry settings object checking step, should I make the algorithm take both relevant settings object and the entry settings object as arguments? Or any good idea how to define this algorithm?

/cc @domenic

[annevk]

Yes, that security check is important for Location objects. Is a WindowClient always same-origin?

I think you basically want to make the computation of this array reusable https://html.spec.whatwg.org/multipage/browsers.html#concept-location-ancestor-origins-array and not bother with ancestorOrigins itself (that you'd just define to return such an array).

[jungkees]

Yes, WindowClient is exposed to only service workers, and only same origin clients can be retrieved.

just define to return such an array

That sounds good.

Out of curiosity, why is the security check in the attributes of Location against the entry settings object?

[annevk]

That is what browsers implement. I believe it comes into play when you use document.domain, but it's been a while. We might change away from entry if we can, we'll see.

[jungkees]

I see. So it was in this list: whatwg/html#1431 (comment)