W3C home > Mailing lists > Public > public-device-apis@w3.org > June 2014

Re: [vibration] Mozilla Vibration API status

From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
Date: Tue, 3 Jun 2014 12:38:46 +0000
To: Mounir Lamouri <mounir@lamouri.fr>
CC: W3C Device APIs WG <public-device-apis@w3.org>, Frederick Hirsch <w3c@fjhirsch.com>, Marcos <marcos@marcosc.com>
Message-ID: <163B10F8-FD08-4E07-BAF6-29540B1DC41A@intel.com>
On 03 Jun 2014, at 12:22, Mounir Lamouri <mounir@lamouri.fr> wrote:

> I updated Mozilla implementation indeed but I haven't modified Gecko's
> code to handle the step 5. It's not clear to me why this is required by
> the spec. Is there actually a way to test that behaviour? My
> understanding is that if vibrate() is called, the previous vibrate()
> should be cancelled so step 5 is mostly an implementation detail. Am I
> missing something?

You are correct in that there is no way to test the behaviour with the current API. This is an optimization, perhaps a premature one.

For the context, this is the step:

[[

5. If the length of /pattern/ is even and is not zero, then remove the last entry in /pattern/.

]]

Let’s look at the following example, and assume the implementation-dependent maximum duration for a single vibration entry is greater than 9999:

navigator.vibrate([1, 9999]);

Without the step 5, a pre-existing instance of the processing vibration patterns algorithm would be running for the browsing context for 10 seconds, instead of 1 ms. That means that with another vibrate() within 10 seconds we’d enter the substeps of step 10, and cancel the pre-existing instance, yielding the same result as if we’d implement step 5.

We can make the step 5 a non-normative note, say “MAY remove the last entry” given this is not testable, or drop it altogether.

WDYT?

FWIW, Chromium implements this step [1].

Thanks,

-Anssi

[1] https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/modules/vibration/NavigatorVibration.cpp&l=65
Received on Tuesday, 3 June 2014 12:39:29 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:03 UTC