W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2011

Re: [vibration] Preliminary thoughts on the vibrator spec

From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
Date: Thu, 10 Nov 2011 14:10:08 +0200
Cc: Justin Lebar <jlebar@mozilla.com>, <public-device-apis@w3.org>, <public-device-status@w3.org>
Message-Id: <1ADC65DD-533F-4F2C-A713-6C1066E9FD28@nokia.com>
To: ext Jonas Sicking <jonas@sicking.cc>
Hi Jonas,

On 10.11.2011, at 1.18, ext Jonas Sicking 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.

The arguments are type of 'unsigned long' and 'unsigned long[]'. According to Web IDL (http://dev.w3.org/2006/webapi/WebIDL/#es-unsigned-long):

* negative values throw a TypeError

* undefined throws a TypeError (ToNumber(undefined) === NaN as per ECMA-262, and NaN throws TypeError as per Web IDL)

* null is converted to 0 (ToNumber(null) === +0 as per ECMA-262), and thus vibrate(null) should behave similarly to vibrate(0)

Given this, I dropped undefined, but kept null. So all these will cancel the operation similarly:


Does this sound reasonable?

>>>    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.

Agreed. I changed pause to suppress and resume to restore. Feel free to suggest better wording.

>> 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.

Added the following normative prose as per your proposal:


An implementation should be allowed to disable vibration in any way if it wants to for security or privacy reasons.



Received on Thursday, 10 November 2011 12:10:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:32 UTC