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

Minimize the usage of the incumbent concept #1430

Open
domenic opened this Issue Jun 15, 2016 · 2 comments

Comments

3 participants
@domenic
Member

domenic commented Jun 15, 2016

This is a tracking bug, both for HTML and for the wider web ecosystem, to see if we can minimize the number of places that use the incumbent global/settings object/realm. Originally this was https://www.w3.org/Bugs/Public/show_bug.cgi?id=26603.

Here is our HTML checklist:

Other specs:

If you have other specs that use the incumbent concept, comment here and I will update the OP.

@domenic domenic self-assigned this Jun 15, 2016

domenic added a commit that referenced this issue Jun 29, 2016

Use current instead of incumbent + entry in worker constructors
As shown by https://settings-object-worker-client-abibrisfdk.now.sh, all
browsers use the current settings object for the fetch client, i.e. the
"outside settings", instead of the incumbent settings object. (Except we
do not know the result in Edge, since they don't seem to send a Referer
header for us to inspect.) Part of #1430.

As shown by
https://settings-object-worker-client-wellwosyqf.now.sh/entry/entry.html,
all browsers also use the current settings object for URL resolution,
instead of the entry settings object. Part of #1431.

domenic added a commit that referenced this issue Jun 29, 2016

Use the Window's associated Document for allow-modals sandbox checks
This fixes #1206. As noted there, the previous indirections were wacky
and unnecessary.

This matches the behavior as implemented in Chrome, as shown by
https://allow-modals-check-zzvyjxgdhg.now.sh.

This also helps the efforts in #1430.

domenic added a commit that referenced this issue Jun 29, 2016

Use the Window's associated Document for allow-modals sandbox checks
This fixes #1206. As noted there, the previous indirections were wacky
and unnecessary.

This matches the behavior as implemented in Chrome and Firefox Nightly
(which are the only browsers which implement sandboxing of modals), as
shown by https://allow-modals-check-zzvyjxgdhg.now.sh/entry.html.

This also helps the efforts in #1430.

domenic added a commit that referenced this issue Jun 29, 2016

Use the Window's associated Document for allow-modals sandbox checks
This fixes #1206. As noted there, the previous indirections were wacky
and unnecessary.

This matches the behavior as implemented in Chrome and Firefox Nightly
(which are the only browsers which implement sandboxing of modals), as
shown by https://allow-modals-check-pijoohuobf.now.sh/entry.html.

This also helps the efforts in #1430.

domenic added a commit that referenced this issue Jun 29, 2016

Use the Window's associated Document for allow-modals sandbox checks
This fixes #1206. As noted there, the previous indirections were wacky
and unnecessary.

This matches the behavior as implemented in Chrome and Firefox Nightly
(which are the only browsers which implement sandboxing of modals), as
shown by https://allow-modals-check-yucxowumar.now.sh/entry.html.

This also helps the efforts in #1430.

annevk added a commit that referenced this issue Jul 6, 2016

Use current instead of incumbent + entry in worker constructors
As shown by https://settings-object-worker-client-abibrisfdk.now.sh, all
browsers use the current settings object for the fetch client, i.e. the
"outside settings", instead of the incumbent settings object. (Except we
do not know the result in Edge, since they don't seem to send a Referer
header for us to inspect.) Part of #1430.

As shown by
https://settings-object-worker-client-wellwosyqf.now.sh/entry/entry.html,
all browsers also use the current settings object for URL resolution,
instead of the entry settings object. Part of #1431.

domenic added a commit that referenced this issue Jul 12, 2016

Use current settings object in content document definition
Since this is a same origin-domain check, we can use any settings
object, as they are all same origin-domain. Part of #1430.

domenic added a commit that referenced this issue Jul 18, 2016

Use current settings object in content document definition
Since this is a same origin-domain check, we can use any settings
object, as they are all same origin-domain. Part of #1430.

domenic added a commit that referenced this issue Jul 19, 2016

Use only the incumbent global in postMessage
Previously one of the origin checks was performed with the entry
settings object, while the origin and source attributes of the resulting
MessageEvent were derived from the incumbent settings object. At least
WebKit and Blink appear to use the same global for both, and it makes
sense to align the checks on the same global.

The difference is only observable in test cases that fiddle with
document.domain, as entry and incumbent are always same origin-domain
(but, in document.domain cases, not always same origin).

Fixes #1542. Helps #1431 but hurts #1430.

domenic added a commit that referenced this issue Jul 20, 2016

Use only the incumbent global in postMessage
Previously one of the origin checks was performed with the entry
settings object, while the origin and source attributes of the resulting
MessageEvent were derived from the incumbent settings object. At least
WebKit and Blink appear to use the same global for both, and it makes
sense to align the checks on the same global.

The difference is only observable in test cases that fiddle with
document.domain, as entry and incumbent are always same origin-domain
(but, in document.domain cases, not always same origin).

Fixes #1542. Helps #1431 but hurts #1430.

domenic added a commit that referenced this issue Oct 24, 2016

Editorial: use "current settings object" for importScripts
Since we are inside a worker, current/incumbent/entry/relevant are all
equivalent. Helps with #1430.

annevk added a commit that referenced this issue Oct 25, 2016

Editorial: use "current settings object" for importScripts
Since we are inside a worker, current/incumbent/entry/relevant are all
equivalent. Helps with #1430.
@xfq

This comment has been minimized.

Show comment
Hide comment
@xfq

xfq Aug 16, 2017

Contributor
Contributor

xfq commented Aug 16, 2017

I just filed w3c/csswg-drafts#1725 and w3c/sensors#253.

anssiko added a commit to w3c/sensors that referenced this issue Aug 24, 2017

Fix #253: Stop using incumbent settings object
This change is editorial.

Tracking bug: whatwg/html#1430
@anssiko

This comment has been minimized.

Show comment
Hide comment
@anssiko

anssiko Aug 24, 2017

@domenic, w3c/sensors updated, so you can tick that box in the OP.

anssiko commented Aug 24, 2017

@domenic, w3c/sensors updated, so you can tick that box in the OP.

anssiko added a commit to w3c/battery that referenced this issue Aug 31, 2017

Stop using incumbent settings object
This change is editorial.

Tracking bug: whatwg/html#1430

anssiko added a commit to w3c/battery that referenced this issue May 22, 2018

Stop using incumbent settings object
This change is editorial.

Tracking bug: whatwg/html#1430
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment