Take the following code example:
someCondition = false;
async function onClick(event) {
if (someCondition) {
await Promise.resolve(); // Or any other async function.
}
event.stopPropagation();
}
let called = false;
onClick({ stopPropagation: () => called = true })
.catch(console.error);
console.log("Called:", called);
The callback is called synchronously or not based on someCondition. Is
it a deliberate choice that the first chunk of an async function is
executed synchronously instead of waiting for the next microtask?
This behaves in the same way as the current Task.jsm scheduling, since
we never fixed bug 1030075, but is subject to subtle bugs when used with
callbacks, just like in the example above.
On the other hand, it allows async functions to invoke callbacks for DOM
events, without wrapping them in a normal function. This is handy but
it isn't a good practice anyways, because if the async function throws
an exception it would lead to an unhandled rejection (as if the "catch"
in the example above was missing).
I haven't found any regression test for this in our implementation, and
I guess we should add one either way.
Cheers,
Paolo
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
