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

I've filed this as a bug against Chromium. If you'd like to follow along,
star https://code.google.com/p/chromium/issues/detail?id=579628.

It may make sense to explicitly call this usecase out in the spec. The
ambiguous language makes this difficult to rely on.

Taking off my browser dev hat and putting on my web developer hat... On my
site, given the current language of the spec, I have no option but to
detect desktop browsers and show a warning for them. This doesn't work for
devices like the Nexus 7 without vibration hardware, but it covers the
common case since most mobile devices have vibration hardware.

On Mon, Jan 25, 2016 at 4:39 PM, Nick Doty <npdoty@ischool.berkeley.edu>
wrote:

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