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)

[jungkees]

Addressed: 58be22d

Closing.

[wanderview]

Note, location.ancestorOrigins has a privacy issue here:

whatwg/html#1918

Which blocks gecko implementation for the moment.

[jakearchibald]

Implementations haven't removed this, we should add it back to the spec but mark it as at risk.

We should look at usage and see if we can at the very least move it to windowclient.

"auxiliary" is the only feature ancestor origins doens't give us.

[annevk]

I refer you back to #732 (comment).

[jungkees]

We should look at usage and see if we can at the very least move it to windowclient.

@mattto, @wanderview, do you happen to have any data on the usage of Client.frameType?

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

For the client opened with "rel=noopener", Chromium returns "top-level", and Firefox returns "auxiliary" at the moment.

@annevk, do you have any update on #1075 (comment)?

[jungkees]

I'm planning to add frameType back. EdgeHTML, Chromium, Gecko all maintain it. @cdumez, does WebKit support it?

[annevk]

Hmm, it seems that'd become redundant with whatwg/fetch#755 too, but if implementations cannot remove it...

[jungkees]

Yeah, implementations have maintained it so far, and client.frameType can also be accessed out of fetch event handlers, too.