Missing tasks in parallel steps in Handwriting Recognition API

[dontcallmedom-bot]

While crawling Handwriting Recognition API, the following algorithms fire an event, or resolve or reject a Promise, within a step that runs in parallel without first queuing a task:

• The navigator-query-handwriting-recognizer algorithm resolves/rejects a promise directly in a step that runs in parallel
• The navigator-create-handwriting-recognizer algorithm resolves/rejects a promise directly in a step that runs in parallel
• The handwriting-drawing-get-prediction algorithm resolves/rejects a promise directly in a step that runs in parallel

See Dealing with the event loop in the HTML specification for guidance on how to deal with algorithm sections that run in parallel.

_{Cc @dontcallmedom @tidoust}

_{This issue was detected and reported semi-automatically by Strudy based on data collected in webref.}

[wacky6]

Hey @dontcallmedom, I've made a draft and have some questions:

• Is there a guidance on which task source to use?
• Do we need to explicitly call out the realm (in our case, it's always the realm of this)? Is the intention about "make sure every WebIDL objects is unambiguously associated with a realm"?

[tidoust]

• Is there a guidance on which task source to use?

Not really, see w3ctag/design-principles#38 for a discussion on this. Basic guideline is to create a dedicated task source for related events, so as to leave freedom to implementations to order these tasks relative to other (unrelated) tasks.

• Do we need to explicitly call out the realm (in our case, it's always the realm of this)? Is the intention about "make sure every WebIDL objects is unambiguously associated with a realm"?

Yes. Specs such as DOM or HTML now include steps in their algorithms to initialize the realm and call it out in the call to "queue a global task", for example, see timeout(milliseconds). More specs now also do that to associate objects with realms more explicitly.

Calling things out has the advantage of removing all possible ambiguities. It also makes it easier to spot potential issues automatically (e.g., tasks where the realm is actually unclear). Now, from a readability perspective, it's certainly tempting to write a more generic "hey, the realm in the algorithms defined in this spec is always the same and unambiguous, so we won't repeat it everywhere".

A middle-ground approach that we're trying in the Presentation API is to define a wrapping queue a [custom] task algorithm that sets the parameters and calls "queue a global task" and that then gets used in the rest of the spec. The analysis tool will get lost for now because it does not yet follow algorithms, but hopefully it can become smart enough over time to understand this pattern.

[wacky6]

Thanks for the feedback, I've updated the draft :)