Task queueing

[annevk]

You cannot resolve promises while in parallel. This is unfortunately somewhat common (and broken) copypasta. You need to queue a task ideally one of the newer queue a task algorithms that takes a global and such.

[jyasskin]

What would go wrong if we defined an HTML-level version of https://webidl.spec.whatwg.org/#resolve that checked for being [=in parallel=] and called https://html.spec.whatwg.org/multipage/webappapis.html#queue-a-global-task on the promise's relevant global?

[annevk]

I like that idea. I think it would work. Oftentimes though it's not just resolving that needs to happen, but also other state updates. But perhaps it can take an optional list of steps for that. Something like "queue a task and resolve". cc @domenic

(In theory I think the global can have been GC'd, but that's an existing problem.)

[domenic]

This seems like unnecessary magic to me. And it's missing a task source; you need to pick one.

[annevk]

I was assuming it would still take a task source, but instead of a global it would take a promise it would resolve at the end. But yeah, maybe it's a bit much. Also if you need to create the value to resolve with you'd also have to do that as part of the task, so...

[domenic]

Yeah. I generally prefer to have the separate threads have clear distinct indentation levels, so you can tell when messages are being passed across such boundaries...

[annevk]

You used "queue a task" to resolve this which is kinda deprecated.

[marcoscaceres]

Ok, no problem. Will fix next week.

[marcoscaceres]

Ok, I just realized that we now have a mismatch between the permission store and the eventing model.

Updating the permission store should be causing queue global tasks to fire "change" events across the relevant navigables and workers.

Also, web driver part of the spec should just be updating the permissions store, not managing its own tasks.

[johannhof]

@marcoscaceres want to file a new issue for that?