Re: [vibration] Preliminary thoughts on the vibrator spec

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

Jonas> I think "is" would be more correct than "should be".

This is still too restrictive.  An implementation may also disable
vibration just because the user asked.  Also, I don't know what it
means to disable vibration "in any way."

How about we add a step to the algorithm, between steps 8 and 9:

"9) An implementation may abort the algorithm at this point.

"Non-normative note: For example, an implementation might abort the
algorithm because the user has set a preference indicating that pages
at a given origin should never be able to vibrate the page, or an
implementation might cap the total amount of time a page may cause the
device to vibrate and reject requests in excess of this limit."

On Thu, Nov 10, 2011 at 12:18 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Thu, Nov 10, 2011 at 4:10 AM, Anssi Kostiainen
> <anssi.kostiainen@nokia.com> wrote:
>> 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:
>>
>> vibrate(null)
>> vibrate(0)
>> vibrate([])
>>
>> Does this sound reasonable?
>
> Is this the case even when there are overloads? In that case type
> coercion happens much more rarely since we don't know what type to
> coerce to.
>
>>>> 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.
>>
>> ]]
>
> I think "is" would be more correct than "should be".
>
> / Jonas
>

Received on Friday, 11 November 2011 21:17:44 UTC