Re: Vibration API: making feature detection possible

I believe one reason for not doing this is to reduce the possibility of fingerprinting through feature detection.

Is there a strong reason to need to know whether or not vibration is enabled, when asking for vibration with the expectation for best effort may be good enough?

What is the use case for the change? If vibration is not possible what would be reasonable fallbacks (flash the screen a la emacs)?

regards, Frederick

Frederick Hirsch
Nokia



On Oct 8, 2013, at 12:34 PM, ext Michael van Ouwerkerk 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.

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.

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?

Regards,

Michael van Ouwerkerk