Re: [screen-wake-lock] "Release a wake lock": should we queue a task to fire the "release" event? (#293)

That someone would probably be me anyway :-) [Dealing with the event loop from other specifications](https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-for-spec-authors) was very helpful, but it also left me with some questions about object creation in parallel steps and how promises and queued tasks are supposed to work together. It also left me paranoid about having to think about realms, global objects, task sources and objects creation and manipulation everywhere :-)

These are all the parts of the spec that have "in parallel" in their text, along with some questions and comments:

* The [obtain permission](https://w3c.github.io/screen-wake-lock/#dfn-obtain-permission) algorithm:
  * Says "run these steps in parallel", probably because it can block on user-facing permission prompts
  * Can IDL dictionaries (e.g. `PermissionDescriptor`) be created when "in parallel"?
  * Maybe it could possibly be replaced by ["request permission to use"](https://w3c.github.io/permissions/#request-permission-to-use)? Not sure if that always needs to be invoked in parallel or not.

* ["Acquire a wake lock" algorithm](https://w3c.github.io/screen-wake-lock/#acquire-wake-lock-algorithm):
  * Entire algorithm is currently supposed to run "in parallel"
  * ... but it references the "responsible document" and the "current settings object"
  * Maybe only run "Ask the underlying OS to acquire the wake lock of type `type`" in parallel?

* ["Release a wake lock" algorithm](https://w3c.github.io/screen-wake-lock/#release-wake-lock-algorithm):
  * Entire algorithm is currently supposed to run "in parallel", and one of the steps is supposed to run "in parallel" again
  * Despite supposedly running "in parallel", references "responsible document" and "current settings object"
  * Possible fixes:
    1. Only run step 5 (asking the OS to release the lock) in parallel
    1. Stop queuing a task to `[[Released]]` to `true` and fire "release" event (we're missing a task source anyway)
    1. Call the OS last? More generally speaking, if there are two subsequent parallel steps, one to queue a task to fire an event and another to resolve a promise, will the promise always be resolved after the event is fired?

* [WakeLock.request()](https://w3c.github.io/screen-wake-lock/#dom-wakelock-request):
  * The "in parallel" steps handle permission request and invoking the "acquire a wake lock" algorithm to, among other things, ask the OS for a lock.
  * Not sure how to handle promises, permissions and OS calls together: permission request can block, so it always seems to be done "in parallel".
  * Can IDL interfaces (e.g. `WakeLockSentinel`) "in parallel"?
  * Not clear how resolving a promise in a parallel step (with an object created in parallel) works.
  * Does that "in parallel" step need to be broken into multiple steps?

* [WakeLockSentinel.release](https://w3c.github.io/screen-wake-lock/#dom-wakelocksentinel-release):
  * Possibly no need to change anything if the "release a wake lock" algorithm is adjusted?
  * Dunno how to avoid running the entire "release a wake lock" algorithm in parallel because of the promise there


-- 
GitHub Notification of comment by rakuco
Please view or discuss this issue at https://github.com/w3c/screen-wake-lock/issues/293#issuecomment-771758848 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 2 February 2021 16:23:51 UTC