Re: Vibration API: making feature detection possible

On Tue, Oct 8, 2013 at 9:20 PM, <Frederick.Hirsch@nokia.com> wrote:

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

The device being used by the user is already included in the user agent.
 It's not hard to set up a mapping to see which devices have a vibrator.
 The fingerprinting risk then comes down to (1) user-agent specific limits
for the duration, and (2) whether vibration is allowed in the current
context.  Both sound reasonable to expose..

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

Being able to provide alternative behavior when vibration is used as a form
of haptic feedback.

Peter

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