W3C home > Mailing lists > Public > public-device-apis@w3.org > January 2016

Re: [vibration] Returning false if vibration hardware is not present?

From: Nick Doty <npdoty@ischool.berkeley.edu>
Date: Mon, 25 Jan 2016 16:39:24 -0800
Cc: Philip Rogers <pdr@chromium.org>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-Id: <55E9B7C3-AC68-49BE-9B91-81C2DBA82EF2@ischool.berkeley.edu>
To: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>
> On Jan 20, 2016, at 1:55 AM, Kostiainen, Anssi <anssi.kostiainen@intel.com> wrote:
> 
> Hi Philip,
> 
>> On 19 Jan 2016, at 22:11, Philip Rogers <pdr@chromium.org> wrote:
>> 
>> The vibration api is currently spec'd to return false from vibrate(...) if the page is not visible or (optionally) if the user has disabled vibration. Can the spec be amended to return false if vibration hardware is not present too?
> 
> Thanks for your feedback.
> 
> Actually, the following step allows an implementation to return false also if the hardware is not present:
> 
> [[
> 
> An implementation MAY return false and terminate these steps. [1]
> 
> ]]
> 
> The conditions under which false may be returned are intentionally left unspecified -- it would be impossible to enumerate all the possible reasons in the spec, thus the use of somewhat uncommon "MAY". Examples given in the note that follows the step are just informative, and not a complete list.
> 
>> Some mobile devices such as the Nexus 7 do not have hardware support for vibration. I'd like to provide feedback to users when their hardware doesn't support vibration. There is an Android API for accessing this: Vibration.hasVibrator(), though I couldn't find an API on iOS.
> 
> The catch with the current API is, you cannot detect the reason for failure, but I believe your use case does not require that. Knowing that the device did not vibrate when vibrate() was invoked is enough?
> 
>> Ideally we would return a promise but that change is probably not web compatible. Another option is to add something like hasVibrator(). Because false is already returned for a variety of cases where vibration is not possible, I think it makes sense to also return false when hardware support prevents vibration.
> 
> For the background, a similar issue was raised in 2013 [2]. At that time the group decided to not add such a feature to the Vibration API, but was open to consider future APIs with this in mind. For example, the Battery Status API was gated behind a promise for similar reasons. I attempted to summarize the thread at [3].

Curious. I would have guessed that most implementations just wouldn't implement that interface if the hardware wasn't available, and that sites could check that navigator.vibrate was non-null before calling it. (That is, that hasVibrator() or canVibrate() could just be navigator.vibrate != Null.)

As it is now, Firefox on my laptop computer has navigator.vibrate and returns true when called with valid parameters, even though it doesn't perform vibration. That seems like a violation of the current spec, which has "perform vibration" as a mandatory step. If the intended behavior is that user agents should be able to return true even if they're not intending to perform a vibration (reasonable: so that sites can't *know* that they're vibrating the device), shouldn't that be explicitly noted?

—Nick

> If we today have a strong use case for explicit feature detection, wider support from browser vendors, no fingerprinting or accessibility worries, and we're able to expose this new feature in a web compatible way, I believe we could start "Vibration API Level 2" spec and bake such a feature into it. Since this is a new feature, it does not qualify as an errata update for the existing spec that has reached Recommendation aka final stage.
> 
> Thanks,
> 
> -Anssi
> 
> [1] https://www.w3.org/TR/vibration/#dfn-perform-vibration
> [2] https://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0074.html
> [3] https://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0135.html
> 
> 


Received on Tuesday, 26 January 2016 00:40:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:07 UTC