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