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.

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.

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.

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.

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.

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.

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

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

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.

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.

Since we are inside a worker, current/incumbent/entry/relevant are all
equivalent. Helps with #1430.

Since we are inside a worker, current/incumbent/entry/relevant are all
equivalent. Helps with #1430.

This change is editorial.

Tracking bug: whatwg/html#1430

This change is editorial.

Tracking bug: whatwg/html#1430

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

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.

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.

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.

Since we are inside a worker, current/incumbent/entry/relevant are all
equivalent. Helps with whatwg#1430.

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

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

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

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

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

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

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

This will discourage people from using it, helping with #1430. Closes #4229 by superseding it. Note that entry is already non-exported.

This will discourage people from using it, helping with #1430. Closes #4229 by superseding it. Note that entry is already non-exported.