Minimize the usage of the incumbent concept #1430

domenic · 2016-06-15T19:18:56Z

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:

Credential Management should incumbent settings object be relevant settings object? w3c/webappsec-credential-management#53
Blob URLs Stop using the "incumbent settings object" w3c/FileAPI#60
cssom-view [cssom-view] Stop using "incumbent settings object"? w3c/csswg-drafts#1725 [cssom-view] Remove "familiar with" check for move/resize methods w3c/csswg-drafts#6300
Sensor API Stop using "incumbent settings object"? w3c/sensors#253
Battery Status API Checks on allowed usage are specced incorrectly w3c/battery#19
Upgrade Insecure Requests

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

The text was updated successfully, but these errors were encountered:

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.

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.

xfq · 2017-08-16T02:06:39Z

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

This change is editorial. Tracking bug: whatwg/html#1430

littledan · 2018-12-10T08:39:21Z

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 · 2018-12-10T08:45:46Z

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

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

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

domenic · 2021-05-05T23:38:24Z

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.

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

domenic self-assigned this Jun 15, 2016

domenic added the topic: multiple globals label Jun 15, 2016

domenic mentioned this issue Jun 29, 2016

Use current instead of incumbent + entry in worker constructors #1472

Merged

domenic mentioned this issue Jun 29, 2016

Use the Window's associated Document for allow-modals sandbox checks #1473

Merged

domenic mentioned this issue Jul 12, 2016

Which origins to use in postMessage? #1542

Closed

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

Use current settings object in content document definition

7699b11

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

mwatson2 mentioned this issue Jul 14, 2016

Secure origin check should not use "incumbant" settings object w3c/encrypted-media#269

Closed

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

Use current settings object in content document definition

a6a1b71

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 mentioned this issue Jul 19, 2016

Use only the incumbent global in postMessage #1573

Merged

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

Editorial: use "current settings object" for importScripts

413de3a

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

domenic mentioned this issue Oct 24, 2016

Editorial: use "current settings object" for importScripts #1963

Merged

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

Editorial: use "current settings object" for importScripts

a2df643

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

equalsJeffH mentioned this issue Dec 29, 2016

callerOrigin isn't actually the origin of the caller; it's the origin of the callee w3c/webauthn#271

Closed

This was referenced Jan 8, 2017

Please do not use "incumbent" w3c/webappsec-credential-management#54

Closed

should incumbent settings object be relevant settings object? w3c/webappsec-credential-management#53

Closed

Ms2ger mentioned this issue Jan 30, 2017

Stop using the "incumbent settings object" w3c/FileAPI#60

Closed

domenic mentioned this issue Mar 8, 2017

Clarify "settings object" things when calling a custom element constructor #2381

Closed

This was referenced Apr 14, 2017

Simplifying incument realm definition to match Blink? #2535

Closed

Simplify the definition of the "entry" concept #2499

Merged

This was referenced Aug 16, 2017

Stop using "incumbent settings object"? w3c/sensors#253

Closed

[cssom-view] Stop using "incumbent settings object"? w3c/csswg-drafts#1725

Closed

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

Stop using incumbent settings object

f210da7

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

a369bc9

This change is editorial. Tracking bug: whatwg/html#1430

bzbarsky mentioned this issue Oct 24, 2018

Consider defining a Realm (global) for all objects, not just Functions tc39/ecma262#1333

Open

erights mentioned this issue Oct 24, 2018

Old mentions of Realm must be updated to distinguish "root realm" vs "compartment" tc39/proposal-shadowrealm#186

Closed

littledan mentioned this issue Dec 10, 2018

Editorial: Include "legacy" in the name of entry and incumbent #4229

Closed

alice pushed a commit to alice/html that referenced this issue Jan 8, 2019

Use current settings object in content document definition

94fce56

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

Editorial: use "current settings object" for importScripts

b4a5170

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

domenic mentioned this issue Jan 16, 2020

Incumbent seems broken for pending promises #5213

Closed

domenic mentioned this issue Jun 2, 2020

[COOP Reporting] "the environment's top-level browsing context" camillelamy/explainers#4

Open

domenic mentioned this issue Jul 10, 2020

Change MessagePort owner from incumbent to current #5728

Merged

3 tasks

domenic mentioned this issue Jul 10, 2020

Check BroadcastChannel origin against creation-time current #5729

Merged

3 tasks

hiroshige-g mentioned this issue Jul 14, 2020

Propagate active script to callbacks whatwg/webidl#902

Open

domenic mentioned this issue Apr 1, 2021

Having both incumbentNavigationOrigin and the source browsing context's active document's origin seems bad #6514

Closed

domenic added a commit that referenced this issue May 20, 2021

Meta: do not export incumbent settings object

7013d1c

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

domenic mentioned this issue May 20, 2021

Meta: do not export incumbent settings object #6702

Merged

annevk pushed a commit that referenced this issue May 21, 2021

Meta: do not export incumbent settings object

4ba46b0

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

dSalieri mentioned this issue May 8, 2022

Diversity of Realms / Why do we need incumbent settings object for the callbacks #7903

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Minimize the usage of the incumbent concept #1430

Minimize the usage of the incumbent concept #1430

domenic commented Jun 15, 2016 •

edited

Loading

xfq commented Aug 16, 2017

littledan commented Dec 10, 2018

domenic commented Dec 10, 2018

domenic commented May 5, 2021

Minimize the usage of the incumbent concept #1430

Minimize the usage of the incumbent concept #1430

Comments

domenic commented Jun 15, 2016 • edited Loading

xfq commented Aug 16, 2017

littledan commented Dec 10, 2018

domenic commented Dec 10, 2018

domenic commented May 5, 2021

domenic commented Jun 15, 2016 •

edited

Loading