Missing guidance for handling steps that are run "in parallel"

[rakina]

Copied from @annevk's #1 (review) and #1 (comment) :

I'm missing some guidance around "in parallel".
At least abstractly it seems that whenever you do "in parallel" followed by "queue a global task" there's an opportunity for a document to become inactive.
However, HTML will block task processing in that case until the document is active again so you can't really know.
I'm also vaguely reminded of an issue around promises here.
E.g., if we consider https://storage.spec.whatwg.org/#dom-storagemanager-persisted. Should that just work as-is or will any changes be needed?

Maybe the better example would be the persist() method in the same document. It's rather unclear whether or not the state ends up changing or the user gets prompted (or is still prompted when going back if they had not answered yet) depending on when the fully active transition happens. I mean, there is a certainly a way to read it that answers these questions, kinda, but I doubt it's accurate.

So I'm not sure I fully understand the problem here, but I think the main concern is that between the steps listed under "in parallel" blocks, the document could've navigated away and put into BFCache and navigated to again and restored from bfcache, so each step can be separated by multiple navigations and a long gap in time, potentially with some changes to the state of the world happening during that time period.

I think for the latter concern (changes happening during that time period), it's not unique to BFCache? As far as I understand it, steps that are run in parallel can already have long time gaps between them, potentially with some changes that happen between them (either from within that document or from another document). If so, then the steps should already be resilient to that or can't be affected by changes that happen in between the steps? (CMIIW)

For the first concern (each step can be separated by multiple navigations), it is touched a little bit by the "Be aware that per-document state/data might persist after navigation" section, but I guess that is more about states that are saved in the document instead of states within parallel steps. We should probably expand that section to be "Be aware that state/data might persist after navigation" and mention "in parallel" explicitly. Does that sound OK?

Also, for what happens with the user prompt in https://storage.spec.whatwg.org/#dom-storagemanager-persist and https://w3c.github.io/permissions/#dfn-request-permission-to-use, I think that's not really a problem with "in parallel" but more of a general problem with prompts and other UI-triggering things right? If the UI doesn't block navigation/running other tasks, I guess they should be able to add a "fully active" state change listener and decide to hide/re-show the UI or just cancel/fail the request? Maybe we can call out these cases specifically in the "Listen for changes to fully active status" section?

(Thanks again for calling this out @annevk, and sorry if I misunderstand the concern here, I am quite unfamiliar with this part of the spec)

[annevk]

I think you're correct that it's a more general problem.

However, thus far we could mostly (perhaps incorrectly) assume that on "unload" it all gets wiped away anyway. Now there's an opportunity "unload" doesn't really happen (only "pagehide") and things do continue afterward and the task you queued gets run in a revived document. And I think that means that the "in parallel" steps have to account for that happening somehow. E.g., if you prompt the user and then the user navigates, the prompt isn't answered. Was that a "denied"? What does that mean for when the document gets revived and the API gets an answer through the queued task?

[rakina]

Thanks, yeah it sounds like it's worth it to call out those potential problems then. I will work on adding a new "Be aware that navigations can happen between non-synchronous steps" sections to list out the concerns here.