W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2013

Re: Vibration API: making feature detection possible

From: Peter Beverloo <beverloo@google.com>
Date: Thu, 10 Oct 2013 09:26:15 +0200
Message-ID: <CALt3x6kiAnvFELZBPqEiUGvUbmxO-G+1hLf+0karLtkG6YVDUw@mail.gmail.com>
To: Frederick.Hirsch@nokia.com
Cc: mvanouwerkerk@chromium.org, public-device-apis@w3.org
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.


  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
Received on Thursday, 10 October 2013 07:26:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:01 UTC