Re: Vibration: throwing and pause

On Fri, Apr 12, 2013 at 9:57 PM, Justin Lebar <justin.lebar@gmail.com> wrote:
> I kind of like the fact that we throw, since otherwise it's impossible
> for developers to know if their time/pattern has exceeded the UA's
> arbitrary constraints.  Although the UA does in fact have other
> opportunities not to run the requested vibration, it seems useful to
> me for the UA to inform the page "you've got no chance with this one."

The problem I have is that people will test this in one UA, forget
about try/catch, and another new UA running the same code will throw
and will effectively be forced at that point to reverse engineer.


> But I don't feel strongly about this, and I'm happy to defer to Anne's
> judgement.

Maybe instead we should make the method return a boolean so the
developer does not lose that feedback? Returning true if the UA has
decided it will do the vibration and false otherwise?


> I don't know how (unsigned long or sequence<unsigned long>) is different, in
> practical terms, from the overloads (unsigned long) and (unsigned long[]) that
> we have now.  So I probably don't have an opinion on this.  :)

[] at some point defers to sequence<> so it's better to just use the
latter straight away. At least for method and dictionary arguments.
(IDL should probably start enforcing that.)


> The method is definitely not intended to be synchronous in Firefox's
> implementation.
>
> I don't even know what it means to synchronously do an operation like this.
> Obviously the vibrate() call doesn't block until the phone starts
> moving, or something like that.
>
> Could you elaborate on how making this method sync and spinning the event loop
> impacts content authors?  I agree with Anne that making this sync seems Very
> Bad.

Yeah, it should simply return early and then asynchronously do the
vibration bits.


--
http://annevankesteren.nl/

Received on Saturday, 13 April 2013 08:25:22 UTC