W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2012

Re: [Vibration] Feedback on the Vibration API

From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
Date: Wed, 7 Nov 2012 14:12:42 +0200
Cc: "DAP public-device-apis@w3.org" <public-device-apis@w3.org>
Message-Id: <9C7427A7-4DB5-4223-95F1-FA937F19D3F0@nokia.com>
To: David Bruant <bruant.d@gmail.com>, ext Marcos Caceres <w3c@marcosc.com>, ext Justin Lebar <jlebar@mozilla.com>
[+to Justin]

Hi David, Marcos, Justin,

On 6.11.2012, at 15.22, ext Marcos Caceres wrote:

> On Tuesday, November 6, 2012 at 10:07 AM, David Bruant wrote:
>> First, in the spec, it seems that only one app can vibrate at a time

As per the step 8, only one application can vibrate at a time. We landed on this design based on Mozilla's implementation experience, see:


> If this is so, this is a spec bug (or just not correctly worded). I'm fairly certain that notifications can cause the phone to vibrate independent of application (e.g., when you get an SMS).

I think you're right in that trusted (or privileged apps) should be able to vibrate the device even if not visible. Thanks for pointing this out!

To make this clearer, I propose we add something like the following as a note after the step 6 (feel free to propose a better wording):



A trusted (also known as privileged) application that integrates closely with the operating system's functionality may vibrate the device even if such an application is not visible at all, and thus may ignore the previous step.


Alternatively, we could bake similar language in to the algorithm itself. As the algorithm is currently written, we're bailing out at step 6 if the privileged app invoking vibrate() is hidden.

Justin, David, Marcos - does that change make sense to you?

For reference, here's the current algorithm:


Received on Wednesday, 7 November 2012 12:13:19 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:56 UTC