Html: createImageBitmap doesn't queue a task to resolve its promises

[domenic]

In particular, it needs to pick a task source to use. I wonder what implementations do here.

/cc @dtapuska since he's been doing vaguely-related work.

[TimothyGu]

In practice, the only case where the promise is actually resolved in parallel is for Blobs. createImageBitmap() currently has quite a few cases with the following:

1. Run this step in parallel:

   1. Resolve _p_ with _imageBitmap_.

which seems both wrong and unnecessary.

In Chrome, a deprecated "default" task source that doesn't map to any task source in HTML in particular seems to be used. Priority-wise it seems tantamount to DOM manipulation, history traversal, and a slew of others, but I don't think they are the exact same queue.

In Firefox, the catch-all "other" task source is used. This seems to be equivalent to the DOM manipulation task source in HTML as well as many others.

[domenic]

Wow, thanks for doing the research!

For the "wrong and unnecessary" steps, I'm not 100% sure they're wrong and unnecessary. In particular I suspect there is a lot of implementation-specific stuff that might be best done off the main thread and take some time, even if the spec has phrased all of the processing except for the promise resolution as happening on the main thread. If we changed these to just resolve the promise, or to just queue a task to resolve a promise, I believe you could write tests that would demand that the promise be fulfilled within a single event loop turn or so, and that would prevent implementations from taking longer if they need it.

For this "default" task source business, I see a few possibilities:

• Introduce an actual default task source. I worry this might be abused; spec authors already have trouble choosing task sources, and it seems likely they'll all just jump on this one.

• Make it more explicit that the DOM manipulation task source is a sort of fallback default task source you can use for things that don't fit in other places. Maaaybe rename it too.

Paging @bzbarsky for thoughts on that subject.

[bzbarsky]

I guess the really fundamental question is whether we should be encouraging spec authors to effectively create their own task sources where possible, so we minimize ordering dependencies. If we do, the default should be something like "new task source for this one specific caller"...

That said, if UAs in practice don't do that and just serialize more than the spec requires/allows, web pages can, in practice, start to depend on this serialization anyway....

So I'm a bit torn between defaulting to the DOM task source (which makes sense as a default if we have one) and defaulting to "new task source every time" unless someone specifies otherwise. The latter is theoretically nice but practically may not be something browsers end up implementing, so might not end up web-compatible....

(That said, Gecko at least is interested, in our new scheduler, in a "conceptually separate task source for each task, unless specified otherwise" as a behavior, because that will let us have a lot more flexibility in terms of scheduling stuff.)

[bzbarsky]

Oh, and @smaug---- might have thoughts here too.

[annevk]

See #3424 for some WIP that would make this easier to fix.