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

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:19:39 UTC