Re: [vibra] Vibration API -- the first stab

On 2.11.2011, at 21.39, ext JOSE MANUEL CANTERA FONSECA wrote:

>>> is active at a time and any subsequent vibrate() invocation will cancel
>>> the pre-existing operation,
> 
> Well, vibration implementation at the native layer usually does not work
> in that way. There is a vibration request queue that guarantees that
> vibration requests are satisfied for the requested times (but without
> overlapping).

I may have misunderstood what you meant. So you were not suggesting we should expose the content process IDs through the public API like this:

var id = foo.vibrate(5000);
foo.cancel(id);

I'd like to see the public API as simple as possible, and thus keep things like process IDs as implementation details.

> Imagine I have an app with two iframes and from the two iframes I'm
> requesting vibration in overlapping time instants. With your approach what
> it would happen is that one will stop the vibration from the other which
> will incorrect.

Test 7 describes the behavior of Mozilla's implementation in such a case:

  https://bug679966.bugzilla.mozilla.org/attachment.cgi?id=567875

And vibrate() from the second iframe will overwrite the first iframe's vibrate().

The first draft tries to align with Mozilla's current implementation. That said, I'd be surprised if we had captured all the edge cases yet. For example, there's a rather lengthy discussion about race condition avoidance in the Bug 679966. Luckily Page Visibility API already addresses part of the problem spec-wise.

Thanks for the feedback, and let's continue discussion during today's session!

-Anssi

Received on Thursday, 3 November 2011 13:33:32 UTC