Parallelism and task sources about clipboard-apis HOT 2 OPEN

Perhaps "deprecated" is too strong a word. "Unfavored"? "overused"? "Rarely the best choice"? It seems that "in parallel" is often an under-specification because it introduces races into any algorithm steps that operate on global state, and is unnecessary in the case of steps that operate on local state in the context of a returned promise. It was applied more widely in older specs. What few specs I have written have gotten by with a parallel queue, task source, or the use of promises.

In the case of the clipboard, the problem introduced by this "in parallel" is that "check clipboard read permission" should theoretically always return false, because the step "Return true if the current script is running as a result of user interaction with a "Paste" element created by the user agent or operating system." will always fail, at least under my interpretation of "the current script". It is also racy given that it checks user activation, but "in parallel" steps may execute after transient activation has terminated.

Also it now occurs to me that the read() algorithm should just not reference the permission task source at all because it doesn't actually check any permission at the moment.

from clipboard-apis.

• the read() algorithm verifies permissions "in parallel", which is, AFAIU, a deprecated way to describe parallelism.

Is there a documentation regarding to this? I heard that "Return promise and run the remaining steps in parallel" pattern is deprecated but never heard that "in parallel" itself is, that's new to me 👀

from clipboard-apis.