Skip to content
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
14 of 17 tasks
domenic opened this issue Jun 15, 2016 · 5 comments
Open
14 of 17 tasks

Minimize the usage of the incumbent concept #1430

domenic opened this issue Jun 15, 2016 · 5 comments

Comments

@domenic
Copy link
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
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
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
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
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
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 pushed a commit that referenced this issue Jul 6, 2016
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
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
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
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
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
Since we are inside a worker, current/incumbent/entry/relevant are all
equivalent. Helps with #1430.
annevk pushed a commit that referenced this issue Oct 25, 2016
Since we are inside a worker, current/incumbent/entry/relevant are all
equivalent. Helps with #1430.
@xfq
Copy link
Contributor

xfq commented Aug 16, 2017

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

@littledan
Copy link
Contributor

Thanks for this great documentation, @domenic . I missed the big warning in the HTML spec when trying to edit the WebNFC spec; thanks for pointing out the error.

What if we renamed the incumbent to "legacy incumbent" (and ditto for "legacy entry")? The use of this sort of wording in WebIDL makes everything really clear.

@domenic
Copy link
Member Author

domenic commented Dec 10, 2018

That's probably a good idea, thanks for the suggestion! A PR would be appreciated.

littledan added a commit to littledan/html that referenced this issue Dec 10, 2018
Hopefully this will help discourage people from using them.

Also remove "entry global object" as it seemed to be unused.

See whatwg#1430/whatwg#1431
alice pushed a commit to alice/html that referenced this issue Jan 8, 2019
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 whatwg#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 whatwg#1431.
alice pushed a commit to alice/html that referenced this issue Jan 8, 2019
Since this is a same origin-domain check, we can use any settings
object, as they are all same origin-domain. Part of whatwg#1430.
alice pushed a commit to alice/html that referenced this issue Jan 8, 2019
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 whatwg#1542. Helps whatwg#1431 but hurts whatwg#1430.
alice pushed a commit to alice/html that referenced this issue Jan 8, 2019
Since we are inside a worker, current/incumbent/entry/relevant are all
equivalent. Helps with whatwg#1430.
domenic added a commit that referenced this issue Jul 10, 2020
The "owner" of a MessagePort is set a lot, but only *used* for
determining what document (if any) should be associated with that
MessagePort's tasks. I.e., it ensures that when that document becomes
not-fully-active, the tasks are not run.

Tests [1] show that the use of incumbent settings object for the owner
of MessageChannel-created MessagePorts was incorrect. In fact, the
current settings object is used.

This allows for a dramatic simplification, as it means that the
MessagePort's owner is always equal to its relevant settings object.
Thus, we can entirely delete the owner concept, and the associated
specialized "create a new MessagePort object" algorithm.

This does require tweaking the examples of how the incumbent concept
works, now that a simple constructor is no longer available to
demonstrate the point.

This also modernizes the definition of MessageChannel.

Closes #4340. Helps with #1430.

[1]: web-platform-tests/wpt#24566
domenic added a commit that referenced this issue Jul 10, 2020
The "owner" of a MessagePort is set a lot, but only *used* for
determining what document (if any) should be associated with that
MessagePort's tasks. I.e., it ensures that when that document becomes
not-fully-active, the tasks are not run.

Tests [1] show that the use of incumbent settings object for the owner
of MessageChannel-created MessagePorts was incorrect. In fact, the
current settings object is used.

This allows for a dramatic simplification, as it means that the
MessagePort's owner is always equal to its relevant settings object.
Thus, we can entirely delete the owner concept, and the associated
specialized "create a new MessagePort object" algorithm.

This does require tweaking the examples of how the incumbent concept
works, now that a simple constructor is no longer available to
demonstrate the point.

This also modernizes the definition of MessageChannel.

Closes #4340. Helps with #1430.

[1]: web-platform-tests/wpt#24566
domenic added a commit that referenced this issue Jul 10, 2020
...instead of against the creation-time incumbent. This helps with
#1430, and allows a good amount of simplification as we no longer have
to track the "BroadcastChannel settings object" separately from the
relevant settings object.

This also modernizes and cleans up the BroadcastChannel section
editorially.
domenic added a commit that referenced this issue Jul 13, 2020
...instead of against the creation-time incumbent. This helps with
#1430, and allows a good amount of simplification as we no longer have
to track the "BroadcastChannel settings object" separately from the
relevant settings object.

This also modernizes and cleans up the BroadcastChannel section
editorially, and adds messageerror events to the garbage collection
considerations.
domenic added a commit that referenced this issue Jul 13, 2020
The "owner" of a MessagePort is set a lot, but only *used* for
determining what document (if any) should be associated with that
MessagePort's tasks. I.e., it ensures that when that document becomes
not-fully-active, the tasks are not run.

Tests [1] show that the use of incumbent settings object for the owner
of MessageChannel-created MessagePorts was incorrect. In fact, the
current settings object (or relevant settings object of this) is used.

This allows for a dramatic simplification, as it means that the
MessagePort's owner is always equal to its relevant settings object.
Thus, we can entirely delete the owner concept, and the associated
specialized "create a new MessagePort object" algorithm.

This does require tweaking the examples of how the incumbent concept
works, now that a simple constructor is no longer available to
demonstrate the point.

This also modernizes the definition of MessageChannel.

Closes #4340. Helps with #1430.

[1]: web-platform-tests/wpt#24566
mfreed7 pushed a commit to mfreed7/html that referenced this issue Sep 11, 2020
...instead of against the creation-time incumbent. This helps with
whatwg#1430, and allows a good amount of simplification as we no longer have
to track the "BroadcastChannel settings object" separately from the
relevant settings object.

This also modernizes and cleans up the BroadcastChannel section
editorially, and adds messageerror events to the garbage collection
considerations.
mfreed7 pushed a commit to mfreed7/html that referenced this issue Sep 11, 2020
The "owner" of a MessagePort is set a lot, but only *used* for
determining what document (if any) should be associated with that
MessagePort's tasks. I.e., it ensures that when that document becomes
not-fully-active, the tasks are not run.

Tests [1] show that the use of incumbent settings object for the owner
of MessageChannel-created MessagePorts was incorrect. In fact, the
current settings object (or relevant settings object of this) is used.

This allows for a dramatic simplification, as it means that the
MessagePort's owner is always equal to its relevant settings object.
Thus, we can entirely delete the owner concept, and the associated
specialized "create a new MessagePort object" algorithm.

This does require tweaking the examples of how the incumbent concept
works, now that a simple constructor is no longer available to
demonstrate the point.

This also modernizes the definition of MessageChannel.

Closes whatwg#4340. Helps with whatwg#1430.

[1]: web-platform-tests/wpt#24566
@domenic
Copy link
Member Author

domenic commented May 5, 2021

Chromium codesearch indicates incumbent is used for:

  • Location
  • postMessage()
  • window.close()
  • window.open() (some uses not on the above list, although some are part of navigation)
  • window.focus() (not on the above list!!)
  • COOP reporting

Most suspiciously the incumbentNavigationOrigin which the spec uses (see #6514) does not appear very prominently in Chromium's codebase, certainly not in the navigation stack. Instead a couple of navigation call sites (Location and window.open()) use it. Hmm.

domenic added a commit that referenced this issue May 20, 2021
This will discourage people from using it, helping with #1430. Closes #4229 by superseding it. Note that entry is already non-exported.
annevk pushed a commit that referenced this issue May 21, 2021
This will discourage people from using it, helping with #1430. Closes #4229 by superseding it. Note that entry is already non-exported.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

5 participants
@littledan @domenic @anssiko @xfq and others