Re: [vibration] Mozilla Vibration API status

Agreed step 5 can be dropped. It's an implementation detail really.

/m



On Tue, Jun 3, 2014 at 1:38 PM, Kostiainen, Anssi <
anssi.kostiainen@intel.com> wrote:

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