[Bug 24697] Use Promises for lockOrientation

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24697

Domenic Denicola <domenic@domenicdenicola.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |domenic@domenicdenicola.com

--- Comment #2 from Domenic Denicola <domenic@domenicdenicola.com> ---
Hi Mounir,

I'm doing a quick review of the promise usage here and had a few questions and
comments. I hope they're helpful.

----

> 4. If a promise previously created in these steps is pending, it MUST be rejected with a DOMException whose name is AbortError.

This was very confusing, since the promise was previously created in step 3.
Upon re-reading, I understood that you actually meant something like the
following:

- Upon window creation, create an empty list of pending lock-orientation
promises.
- After creating _promise_ in step 3, add it to the list of pending
lock-orientation promises.
- In step 4, loop through the list of pending lock-orientation promises and
reject them with an AbortError; then empty the list.

This would be a much clearer formulation of the situation.

----

> 3. Let promise be a newly-created promise and return it.

Since you have returned in step 3, steps 4 onward will never run. You should
return the promise at the end of the algorithm. There are examples at
https://github.com/w3ctag/promises-guide#examples which may help.

-----

> 9. Otherwise, the next time the orientation changes, before firing the orientationchange event, resolve promise with result. 

What is this "otherwise" attached to? Its closest sibling, 8, is not an "if."
Is it meant to be attached to 8.3? If so, it should be inside the queued task.

Furthermore, I don't understand why you would have this clause at all. The idea
is, if the orientation is already locked, then you should not resolve the
promise, but wait for the user to turn their screen? That seems unrelated. It
seems to me to make more sense to always resolve the promise after locking,
even if locking the orientation does not result in an orientation change. Since
the operation that the promise represents is in fact "locking the orientation."

-----

> void unlockOrientation ();

Is unlocking the orientation always synchronous? That is, can the caller depend
on the orientation being unlocked immediately after making the
`unlockOrientation()` call?

It seems like not, since

> The unlockOrientation() method, when invoked, MUST asynchronously lock the orientation to the default orientation

In that case, a promise should be used so that users can reason about their
program in the sense of knowing when the orientation is finished unlocking.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 23 April 2014 04:08:36 UTC