Browsers don't agree with the incumbent settings handling for Promise reactions

[arai-a]

What is the issue with the HTML Standard?

The HTML spec stores the incumbent settings into the JobCallback, where JobCallbacks are used for Promise reactions and FinalizationRegistry cleanup callbacks.

https://html.spec.whatwg.org/#hostmakejobcallback

HostMakeJobCallback(callable)

...

  1. Let incumbent settings be the incumbent settings object.
  ...
  5. Return the JobCallback Record {
       [[Callback]]: callable,
       [[HostDefined]]: {
         [[IncumbentSettings]]: incumbent settings,
         [[ActiveScriptContext]]: script execution context
       }
     }.

https://html.spec.whatwg.org/#hostcalljobcallback

HostCallJobCallback(callback, V, argumentsList)

...

  1. Let incumbent settings be callback.[[HostDefined]].[[IncumbentSettings]].
  ...
  3. Prepare to run a callback with incumbent settings.
  ...
  7. Clean up after running a callback with incumbent settings.

The behavior for the Promise reactions is covered by the followng WPT testcase.

https://github.com/web-platform-tests/wpt/blob/master/html/webappapis/scripting/processing-model-2/integration-with-the-javascript-job-queue/promise-job-incumbent.html

At the point of reporting this, only Firefox passes this test.

https://wpt.fyi/results/html/webappapis/scripting/processing-model-2/integration-with-the-javascript-job-queue?label=experimental&label=master&aligned

In Firefox implementation, supporting the incumbent settings in Promise reactions has been a problem around the complexity and performance, and if the incumbent settings handling for JobCallback is removed from the spec, it helps much.

Then, to my understanding, Chrome and Safari don't agree with which global to use for the case where the incumbent global is supposed to be used, and it's also different from Firefox, which means the behavior is completely different between browsers. This implies that there's almost no website that actually relies on the incumbent settings handling in Promise reactions (presumably, thanks to the efforts to minimize the incumbent usage in #1430 ), and also which global is used in such case. Thus, removing the incumbent settings handling for the Promise JobCallbacks from the spec and the Firefox implementation won't result in major web-compat issues.

So, I'd like to propose removing the incumbent settings handling from the JobCallback.

Things to do:

• Investigate the FinalizationRegistry usage. If Chrome and Safari also don't implement incumbent settings for FinalizationRegistry, then we can simply remove [[IncumbentSettings]] field. Otherwise we might need to reduce the scope to Promise's case only
• Check how this affect the Prioritized Task Scheduling (Chrome passes the tests for this), which is another consumer of the [[HostDefined]] field
• Check what actually happens in terms of the spec if we just remove the [[IncumbentSettings]]. Which global should be used instead, and which browser matches the behavior right now?

See also:

• Incumbent Globals in Promises web-platform-tests/interop#1143

[domenic]

It has long been known that Firefox has the only really spec-compliant incumbent handling.

For many years, myself and bzbarsky (intentionally not @-mentioning) believed that Firefox's approach was best and we should try to use it across the web platform. Others like @syg, when he worked on Chromium, were willing to agree it was good, although admitted that fixing Chromium to match Firefox was very low priority and realistically might never happen.

In particular, the approach we took highly prized consistency:

• Consistency across different async mechanisms, e.g. promises, finalization registry, callbacks, and even stringy callbacks like setTimeout("func()", 100).
• Consistency between sync and async, i.e., as shown by the example series starting at https://html.spec.whatwg.org/multipage/webappapis.html#example-incumbent-1 .

I think it would be kind of sad to lose this consistency. But perhaps admitting defeat here is the best path forward, if even Firefox's maintainers (i.e., you) no longer value this consistency.

(A similar, and related, discussion is at whatwg/webidl#902.)

I've also had discussions with, IIRC, @verwaest, about specifying something that's closer to Chromium/WebKit's incumbent handling. (Or maybe we were discussing an even simpler model, since his hope was to gain some performance by simplifying what Chromium/WebKit already do? It was several years.) I believe (but am not certain) Chromium/WebKit's incumbent handling loses sync/async consistency, but keeps consistency across the different async mechanisms.

I've summed up some of this in Incumbent Notes, with a particular eye toward what's important to keep working for web compat. tc39/ecma262#3160 (comment) is also a good summary. /cc @nicolo-ribaudo

If you want to go down this route, I think the best path would to be investigate the minimal/most-performant version of incumbent tracking that's necessary for web-compat, and rip out everything else, across the entire web platform. I think an approach that narrowly targets promises and/or finalization registry would not be the best, as it feels like "shipping our org chart".