Re: [vibration] Preliminary thoughts on the vibrator spec

Dave Raggett wrote:
> There may be significant implementation difficulties with resuming the vibration pattern, at least on Android. The
> safest path is to cancel the vibration when switching to another page (or to another Android app), and not to
> resume it when the page becomes visible again.

I'm OK doing this for now and revisiting at a later date if this
behavior is problematic for pages.

-Justin

On Fri, Nov 11, 2011 at 4:16 PM, Justin Lebar <jlebar@mozilla.com> wrote:
>> 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:20:01 UTC