Re: [Vibration API] Confusing list indexing in spec

Hi Robin, All,

On 19.6.2012, at 12.21, ext Robin Berjon wrote:

> On Jun 18, 2012, at 15:40 , Justin Lebar wrote:

[...]

>> And the material points:
>> 
>> * "9. An implementation may abort the algorithm at this point."
>> 
>> This occurs after step 3: "If pattern is 0, or an empty list, cancel
>> the pre-existing instance of the processing vibration patterns
>> algorithm, if any, and abort these steps."  But if a page can't
>> vibrate the device, the page also shouldn't be able to cancel other
>> page's vibrations.
>> 
>> The reason that step 9 appears where it does is because we want pages
>> which can't vibrate the page not to be able to observe this fact.  So
>> error checking on the args has to appear before we abort the
>> algorithm.  I suggest rejiggering the algorithm order so that we do
>> all the error checking upfront, then give the UA a chance to abort,
>> then either cancel or start a vibration.
> 
> Agreed, and good catch. Proposed order: 2, 4, 5, 6, 7, 1 + 9 (merged into a single step), 8, 3 (without cancellation, just abort), 10.

I reordered the algorithm as outlined above. Please check if it looks okay.

>> * "If the device does not provide a vibration mechanism, or it is
>> disabled, the user agent must silently ignore any invocations of the
>> vibrate() method."  Seems to me that we should still do the error
>> checking from the vibration algorithm, but then behave as though no
>> page has permission to frob the vibrator.
> 
> Yes, I think that this should be moved into the algorithm, as part the step labelled "3" in the above rejig. "If pattern is 0 or an empty list, or if the device does not provide a vibration mechanism (or it is disabled) abort these steps."

I moved that into the algorithm.

>> * "When the visibilitychange event [PAGE-VISIBILITY] is dispatched at
>> the Document, the user agent must run the following steps: [either
>> suppress or restore the vibration]".
>> 
>> A few problems here.  First, this only applies if the currently
>> running instance of the vibration algorithm was started by this
>> document.
>> 
>> Second, it's not clear in the spec what it means to "suppress" or
>> "restore" the vibration.
>> 
>> Third, my implementation in Firefox simply cancels the vibration when
>> the page becomes invisible.  If that matches what other
>> implementations do, we should consider changing the spec to match.
> 
> I agree that restoring vibration complicates matters and adds little value (developers who really insist on this can listen to visibilitychange).

I think simplifying this makes a lot of sense, especially given that for more advanced use cases there's the fallback you mentioned. I reworked that part of the spec as I outlined in my reply to Justin.

Thanks for the feedback!

-Anssi

Received on Wednesday, 20 June 2012 11:03:28 UTC