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
domenic opened this issue Jun 15, 2016 · 4 comments
Open

Minimize the usage of the incumbent concept #1430

domenic opened this issue Jun 15, 2016 · 4 comments
Assignees

Comments

@domenic
Copy link
Member

@domenic 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 added 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 added 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 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
This change is editorial.

Tracking bug: whatwg/html#1430
@anssiko
Copy link

@anssiko anssiko commented Aug 24, 2017

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

@littledan
Copy link
Contributor

@littledan littledan commented Dec 10, 2018

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 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 added 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 added 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 added 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 added 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 added 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 added 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
@littledan @domenic @anssiko @xfq and others
You can’t perform that action at this time.