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

Remove frameType, maybe add ancestorOrigins #732

Closed
annevk opened this Issue Aug 17, 2015 · 20 comments

Comments

Projects
None yet
4 participants
@annevk
Copy link
Member

annevk commented Aug 17, 2015

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.)

@annevk annevk added this to the Version 1 milestone Oct 27, 2015

@jungkees

This comment has been minimized.

Copy link
Collaborator

jungkees commented Oct 27, 2015

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

@jungkees

This comment has been minimized.

Copy link
Collaborator

jungkees commented Jan 7, 2016

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

@jakearchibald

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Apr 11, 2016

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

This comment has been minimized.

Copy link
Member

annevk commented Apr 14, 2016

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

@jakearchibald

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Jul 27, 2016

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

@jakearchibald

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Jul 28, 2016

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

This comment has been minimized.

Copy link
Member

wanderview commented Aug 1, 2016

@jungkees

This comment has been minimized.

Copy link
Collaborator

jungkees commented Aug 18, 2016

@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

This comment has been minimized.

Copy link
Member

annevk commented Aug 18, 2016

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

This comment has been minimized.

Copy link
Collaborator

jungkees commented Aug 18, 2016

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

This comment has been minimized.

Copy link
Member

annevk commented Aug 18, 2016

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

This comment has been minimized.

Copy link
Collaborator

jungkees commented Aug 18, 2016

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

@jungkees jungkees added the decided label Sep 19, 2016

@jungkees

This comment has been minimized.

Copy link
Collaborator

jungkees commented Nov 4, 2016

Addressed: 58be22d

Closing.

@wanderview

This comment has been minimized.

Copy link
Member

wanderview commented Feb 15, 2017

Note, location.ancestorOrigins has a privacy issue here:

whatwg/html#1918

Which blocks gecko implementation for the moment.

@jakearchibald jakearchibald reopened this Apr 3, 2017

@jakearchibald

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Apr 3, 2017

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

This comment has been minimized.

Copy link
Member

annevk commented Apr 3, 2017

I refer you back to #732 (comment).

@jungkees

This comment has been minimized.

Copy link
Collaborator

jungkees commented Apr 3, 2018

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

This comment has been minimized.

Copy link
Collaborator

jungkees commented Jun 20, 2018

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

@annevk

This comment has been minimized.

Copy link
Member

annevk commented Jun 21, 2018

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

@jungkees

This comment has been minimized.

Copy link
Collaborator

jungkees commented Jun 21, 2018

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

jungkees added a commit that referenced this issue Jun 24, 2018

Add Client.frameType back
This change adds Client.frameType back with the reasons:
 - Implementations maintain it.
 - It can be accessed outside of fetch event handlers

This change also improved the steps of the algorithms that Create Window Client
invokes by removing unnecessary parallel steps.

Fixes: #732.

jyasskin pushed a commit to jyasskin/ServiceWorker that referenced this issue Aug 7, 2018

Jungkee Song
Remove frameType and add ancestorOrigins
This removes client.frameType attribute and adds
windowClient.ancestorOrigins attribute instead. The rationale behind
this decision is there has not been any solid use cases for frameType,
and ancestorOrigins provides more information to deal with embedded
frame structures.

Fixesw3c#732

jungkees added a commit that referenced this issue Oct 19, 2018

Add Client.frameType back (#1329)
This change adds Client.frameType back with the reasons:
 - Implementations maintain it.
 - It can be accessed outside of fetch event handlers

This change also improved the steps of the algorithms that Create Window Client
invokes by removing unnecessary parallel steps.

Fixes: #732.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment