Re: Vibration API: making feature detection possible

On Oct 8, 2013, at 7:34 PM, Michael van Ouwerkerk <mvanouwerkerk@chromium.org> wrote:

> Hi, I'm currently working on implementing the Vibration API in Blink and Chromium, and I'd like to propose making feature detection possible.

Thanks for your proposal and feedback.

> In its current form, the Vibration API exposes the navigator.vibrate method. When you call it with valid arguments, it returns true. However, this only indicates that the arguments were valid. It does not mean any vibrations have been scheduled. Nothing might happen, perhaps because there is no hardware for it. Do all phones have such hardware? How about tablets, or laptops? Or, perhaps there is no permission for vibrating right now.
> 
> To give web developers an opportunity to provide a fallback for their users, I think it should be possible to detect when they will not be able to vibrate the device.

We thought about this while designing the API, so the behaviour is intentional.

This is similar to how web developers cannot detect if the user has muted the sound of their system. Web Audio API, <audio>, and friends behave the same regardless of the system's ability of actually produce sound. I think that has not been an issue.

In addition, if we'd allow detecting the existence of this particular hardware feature, some developers could end up writing code that does not let the user to proceed if she has not enabled vibration or uses a device that does not have the hardware support for the feature (even if the UA could provide a meaningful fallback).

> The simplest approach might appear to just not expose navigator.vibrate when vibration is not available. However, this would require that the browser detect availability of vibration in the startup path. It might be an asynchronous process as well. This is a problem for implementation in the browser.
> 
> My proposal is that we make use of Promises, so that the setup is asynchronous, and it is clear how to handle failure.
> 
> In JavaScript, it would look something like this:
> window.navigator.getVibrator().then(function(vibrator) {
>   vibrator.vibrate([100, 0, 50]);
> }, function() {
>   // No vibrator is available. Provide fallback or exit.
> });
> 
> What do you think?

This feature has been shipping in Firefox since v16 (Oct 2012) unprefixed [1], and in terms of API behaves the same with and without supporting hardware. Knowing this, I'd be hesitant to change the current specification in incompatible ways.

That said, I think future device-related APIs may want to consider employing a design proposed by Michael. ES6 Modules may provide another future alternative.

Thanks,

-Anssi

[1] https://developer.mozilla.org/en-US/docs/Web/API/Navigator.vibrate

Received on Thursday, 17 October 2013 14:00:09 UTC