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

[vibration] Mozilla Vibration API status

From: Frederick Hirsch <w3c@fjhirsch.com>
Date: Thu, 15 May 2014 18:04:42 -0400
Message-Id: <B8315BBF-D31C-4788-A3B0-5CF9A446E25B@fjhirsch.com>
Cc: Frederick Hirsch <w3c@fjhirsch.com>
To: W3C Device APIs WG <public-device-apis@w3.org>
I took an action on today’s DAP call to check on whether the Firefox implementation is up to date with regards to the Vibration API specification.

Checking the Mozilla developer network site for the Vibration API I see that the description matches the current Vibration CR specification and that the Mozilla page references the current Vibration CR draft.  See https://developer.mozilla.org/en-US/docs/Web/API/Navigator.vibrate

The release history confirms this, with the following notable from the Developer Firefox Release logs:

1. Firefox 11 added support for the Vibration API (13 March 2012), 

2. Firefox 16 un-prefixed it, 

3. Firefox 27 updated to match the CR draft, however returning false when list is too long or has too large entries, instead of throwing’. 

see https://developer.mozilla.org/en-US/Firefox/Releases/27

However, the current CR specification states that if the list length is too long it should be truncated

[[ 	

• If the length of pattern is greater than max length, truncate pattern, leaving only the first max length entries.

 ]]

and also says 

[[

	• For each entry in pattern whose value is greater than max duration, set the entry's value to max duration.

]]

These steps clearly state what an implementation must do, which is not what the Firefox implementation does (according to the note).

That said, the spec in step 9 allows an implementation to return ‘false’ for whatever reason.

[[

9. An implementation may return false and terminate these steps.

]]

(Note that the Firefox bug was reported since earlier Firefox threw an exception, which was a clear problem. This bug has been recorded as fixed
https://bugzilla.mozilla.org/show_bug.cgi?id=884935 )

We probably should discuss the intent of step 9 in the spec which allows an implementation to return false whatever reason  - does that mean it does not need to strictly follow the earlier steps regarding truncation and max values?

I suggest that it should not contradict the earlier steps and that Firefox needs another update  to match the spec . If this is not the case we should add some clarifying text to the document.

What do you think?

regards, frederick

Frederick Hirsch, Nokia
@fjhirsch

For tracker, this should complete ACTION-693
Received on Thursday, 15 May 2014 22:05:12 UTC

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