Re: [vibration] Re: Preliminary thoughts on the vibrator spec

>> If you're going to spec it this way, you should specify what it means
>> to pause the algorithm while a vibration is playing -- presumably you
>> mean that we should cancel the current vibration and resume however
>> many ms are left when the page becomes visible again.
>
> ...I guess that's what you are arguing for here?

What you suggested -- silencing the vibration, but not pausing it --
sounds fine to me.

Note that we'd have to modify the spec to allow a page to cancel its
own vibration when the page is in the background.

-Justin

On Wed, Nov 9, 2011 at 6:18 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Wed, Nov 9, 2011 at 11:39 AM, Justin Lebar <jlebar@mozilla.com> wrote:
>>>> Algorithm step 5: "If pattern is 0, an empty list," **null, or undefined**
>>>
>>> There was earlier discussion that including null and undefined may not make sense so they were
>>> dropped:
>>>
>>> http://lists.w3.org/Archives/Public/public-device-status/2011Oct/0048.html
>>>
>>> I added null and undefined back for now, this should be a minor issue anyway.
>>
>> I don't think it's quite as bad as the following looks:
>>
>>> vibrate(undefined)
>>> vibrate()
>>> vibrate(null)
>>> vibrate(0)
>>> vibrate([])
>>
>> The last two obviously have to be there.  But then any one of the
>> first three implies the other two.  In particular, I think |vibrate()|
>> is less clunky than vibrate(0) or vibrate([]).
>
> I think it's surprising that vibrate() would turn off the vibrator.
>
>> Jonas, do you still think we should get rid of the first three above?
>> I guess I don't feel strongly either way.
>
> Yeah, I see no reason for them to make it into the spec, and no reason
> for us to diverge from the spec.
>
>>>    If the hidden attribute [PAGE-VISIBILITY] is set to true, the user agent must pause [HTML5] the pre-existing instance of the processing vibration patterns algorithm, if any.
>>>    If the hidden attribute [PAGE-VISIBILITY] is set to false, the user agent must resume the pre-existing instance of the processing vibration patterns algorithm, if any.
>>
>> This does not match up with what we're currently doing in Firefox.  We
>> currently just cancel the vibration and don't resume when we go back
>> to the page.
>>
>> This behavior may be more sane, although it's harder to do properly,
>> since it requires sync'ing a browser timer with the internal vibration
>> timer.  When I tell Android to start vibrating, I don't know if it
>> starts running that pattern immediately.
>
> I think the spec is almost right here. Though I agree that it wouldn't
> be a priority for us to implement it this way. But given that it seems
> like we can fix this bug in the future without affecting web compat, I
> don't think that is a problem.
>
> I don't think that the implementation should *pause* the vibration
> pattern. Instead it should suppress it while the page is not visible.
> That way the vibration pattern is still in sync with whatever is going
> on on screen if the user switches away for a second.
>
>> If you're going to spec it this way, you should specify what it means
>> to pause the algorithm while a vibration is playing -- presumably you
>> mean that we should cancel the current vibration and resume however
>> many ms are left when the page becomes visible again.
>
> ...I guess that's what you are arguing for here?
>
>>> 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.
>>
>> Maybe we should have a non-normative section saying that the UA may
>> allow the user to disable vibration globally, per-origin, or however
>> else it wants.
>
> I think it needs to be a normative section, since otherwise it doesn't
> change the normative requirements. But yeah, I think we should simply
> say that an implementation should be allowed to disable vibration in
> any way if it wants to for security or privacy reasons.
>
> / Jonas
>

Received on Wednesday, 9 November 2011 23:28:12 UTC