Update implementation report

[reillyeon]

https://github.com/w3ctag/obsoletion/issues/7 raises the concern that the current implementation report shows that Firefox supports the API while Mozilla has in fact removed (see bug 1653318).

The implementation report should be updated and without a second implementation this specification no longer meets the requirements for advancing to a W3C Recommendation and is thus a candidate for transition to an Obsolete Recommendation.

[marcoscaceres]

That would be great. At the same time, it would be good to discuss what use cases are covered by Gamepad’s haptics and some WebApps members have suggested maybe starting to think about incubating something more modern for haptics.

For example: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/HapticsDevice/explainer.md

My point being that we have really good/interoperable alternatives and path forward even if this API gets obsoleted.

[anssiko]

The WG should update the implementation report and look beyond https://wpt.fyi/results/vibration e.g. https://caniuse.com/vibration that keeps track of other browsers. The latter suggests there's a second implementation to be found. Contributions welcome from folks who have access to any of those browsers on applicable platforms to help contribute test results.

How to evolve this API is an exciting but a separate discussion from implementation report. The group has kept a record of new proposals brought to its attention and we've discussed with folks who have worked on domain-specific capabilities e.g. gamepad specific haptics to understand their requirements. The group's position has been this API is positioned as the lowest common denominator across devices and remains a useful feature for the largest user base, complementary to domain-specific haptics features. With time, it might be that the baseline LCD will move so that we can update this API to consider new features. One of the possible such features under consideration is strength control https://github.com/w3c/vibration/issues/17 that might be soon about to reach the level it could be considered. Contributions welcome in this area too from interested folks.

[marcoscaceres]

@reillyeon, would you mind updating the title of this issue to "Proposal to obsolete this Recommendation"? 🙏

@anssiko, which second independent implementation would meet the requirement?

e.g. https://caniuse.com/vibration that keeps track of other browsers.

Note that you need other engines, not other "browsers". If those are all Chromium variants, then that doesn't count as independent implementations and this is still in violation and should be Obsoleted.

Chromium Engine

• Chrome: Chromium
• Edge: Chromium
• Opera: Chromium
• Chrome for Android: Chromium
• Samsung Internet: Chromium
• Opera Mobile: Chromium
• UC Browser for Android: Chromium
• QQ Browser: Chromium
• Baidu Browser: Chromium

So, where is the second implementation with actual/significant users? (i.e., something worthy of a W3C Recommendation)? Particularly if the Gecko implementation is just lying, and the other browser engines already made it crystal clear they are not interested in this API in this particular shape?

With time, it might be that the baseline LCD will move so that we can update this API to consider new features. One of the possible such features under consideration is strength control https://github.com/w3c/vibration/issues/17 that might be soon about to reach the level it could be considered. Contributions welcome in this area too from interested folks.

It would be terribly bad if DAS again started working on anything related to this without participation from other implementers (and somewhat naive to think just adding "strength control" would meet the use cases, requirements, and user expectations of modern haptic hardware). It's also not in Scope of DAS's charter to do haptics: https://www.w3.org/2024/02/das-wg-charter.html#scope

what would this fall under? The charter says that Vibration is only in maintenance mode new features wouldn't be in scope of DAS's charter.

[marcoscaceres]

Just also noting the spec on TR hasn't been updated since 18 October 2016. Although I see some updates/fixes to the Editor's draft, but no effort to update the actual Recommendation on TR.

The group's position has been this API is positioned as the lowest common denominator across devices and remains a useful feature for the largest user base, complementary to domain-specific haptics features.

I think this the position I'd like to challenge. The group may feel this way, but it might not be the best position to hold for the W3C as a whole. DAP hasn't met its expectations of maintaining the REC, nor continuing to track the actual implementation status of the specification (it's been 7 years and 7 months since this spec was updated on TR, and still has not received a second implementation... with the other second implementation removing support for it!).

DAS hasn't even bothered to create or maintain an Errata (404): https://www.w3.org/das/vibration-errata.html

Due to all of the above, it seems prudent to Obsolete it and let's start on something newer/better.

[anssiko]

This issue should be focused on discussion on implementation report update.

It is my responsibility as the chair to remind you that the process-defined https://www.w3.org/2023/Process-20231103/#implementation-experience does not talk about engines. These are the rules we follow and adhere to in W3C Working Groups.

The DAS WG will carefully review the implementation experience. It is expected to take time due to diversity of implementations. All implementations are important to the WG. One possible approach to fix this issue would be to refer to https://wpt.fyi/results/vibration but that captures only a subset of implementations.

[marcoscaceres]

Right, so that according to the Process, it’s the Team (not the Chair, nor Working Group!) that gets to decide what Implementation experience is.

So, I think we should get the Team to review these claims.

@plehegar can you help us evaluate the situation here? The claim that this is in any way interoperable seems bogus at best. Should other working groups water down their definition of multiple independent implementations to a single engine like DAS does?

[marcoscaceres]

As requested, I filed another issue: https://github.com/w3c/vibration/issues/34

[anssiko]

Vibration API on Firefox 126.0, all the automated tests show green.

Even if just stubs, for web compatibility reasons, the WG will continue the maintenance of this specification as approved by W3C members on February 21st, 2024.

[marcoscaceres]

So it’s ok that an implementation needs to lie? Again, didn’t we establish that the Team needs to make the determination if this has interop per the Process?

[marcoscaceres]

Even if just stubs, for web compatibility reasons, the WG will continue the maintenance of this specification as approved by W3C members on February 21st, 2024.

DAS can maintaining it but I still hold the W3C needs to reconsider the Recommendation designation because it doesn't have two interoperable implementations. If DAS is going to maintain it, its designation should change to something else.

However, the ask to Obsolete it is also fair. DAS should seriously consider that.

[marcoscaceres]

I've pinged @plehegar and @himorin on email to get the Team's position on this - as it was on the Team to make the determination on implementation experience as per the process, which no longer holds.

[plehegar]

From a Process perspective, the Team doesn't re-evaluate a Recommendation nor its implementation report. Once a decision has been announced, there is a period to appeal but, after that, it is set in stone without possibility of appealing.

To revisit the status, you need to apply "Process for Rescinding, Obsoleting, Superseding, Restoring a Recommendation", ie a request to obsolete the specification.

In this case, the Vibration API is listed in the DAS charter (section 2.3 maintenance), so the request has to go to the DAS Working Group. It cannot go to the Team (see below however), nor the TAG.

You did the right thing to raise the matter to the responsible working group, ie you raised a request to obsolete the Recommendation to the Devices and Sensors Working Group.

Now, the Working Group has to make a decision regarding your request within 90 days (August 15 or so since your request was done on May 17).

If the Group makes a decision, it may be formally objected.

If the Group declines to obsolete, raising a formal objection will allow the Team to investigate and, unless the Team finds consensus, the matter will be referred to a W3C Council.

If the Working Group doesn't answer by August 15 or so, you are authorized to request that the Team submit your request directly to the Advisory Committee.

[marcoscaceres]

Thanks @plehegar. That clarifies things. I'll wait and see how things go and if the WG is willing to revise the status.

[marcoscaceres]

@anssiko, why did you close it? Please leave this open until there is some proper discussion around this as per @plehegar comment.

[marcoscaceres]

I raise a formal objection to allow the Team to investigate the claim/rationale:

The W3C Vibration API is falsely claiming to be implemented by Firefox, as indicated in the implementation report. In reality, Firefox no longer supports the API, in that it doesn't actually vibrate. Furthermore, the specification hasn't received interest from any other implementer in years.

Additional reasons for obsoleting the Vibration API include:

• Privacy Concerns: The Vibration API can potentially be used in conjunction with other APIs to track or fingerprint devices. For instance, by generating specific vibration patterns and monitoring the timing and response of those vibrations through sensors or other feedback mechanisms, malicious actors could create a unique identifier for a device. This risk is heightened when combined with other data points, leading to more accurate device or user tracking. The specification itself already acknowledges these privacy concerns, but they remain unresolved in practice.

• User Experience: Haptic feedback from vibration can be perceived as intrusive and annoying by users, which is why some browsers have disabled or limited its use.

• Technological Redundancy: Modern devices and platforms offer more advanced and flexible haptic feedback mechanisms that are not reliant on the web's Vibration API (e.g., Gamepad API).

[reillyeon]

The W3C Vibration API is falsely claiming to be implemented by Firefox, as indicated in the implementation report.

I can't find instructions for how an implementation report should be produced but I think the problem here is relying on WPT results for an API which can be trivially implemented so as to pass the tests without being functional. By doing this Firefox makes the WPT results look like it supports the API when it doesn't. A human writing an implementation report wouldn't claim that Firefox supports the API but the tests can't tell the difference.

Some formal guidance on how groups should produce and maintain implementation reports would be appreciated.

@anssiko, I am requesting as a Chair of this group that you, as an Editor of this specification, produce a manually-curated implementation report which better reflects the implementation status of this API.

@marcoscaceres, please clarify whether your Formal Objection is limited to this misrepresentation of the implementation status or if you will persist is requesting the Team consider overriding the group's decision to continue work on this deliverable.

[marcoscaceres]

@marcoscaceres, please clarify whether your Formal Objection is limited to this misrepresentation of the implementation status or if you will persist is requesting the Team consider overriding the group's decision to continue work on this deliverable.

I think it's both:

1. the misrepresentation of the implementation status.
2. The group's decision to continue work on this deliverable.

For 2. the Scope of the Charter is:

• reacting to device power status
• preventing the screen from turning off under certain conditions
• preventing the system from turning off under certain conditions
• accessing nearby devices without physical contact
• responding to ambient light levels of the device’s environment
• reacting to changes in motion and orientation of the hosting device
• providing location information, either of the hosting device or a location selected by the user

So my reading of the DAS's charter's Scope is that haptics/vibrations are not in scope.

WebApps WG, on the other hand, has haptics explicitly in Scope:

• Haptic input devices and their emitted events and/or data.

And lists a potential new deliverable from the WICG specifications section:

Haptics. An API allowing web applications to interface with haptic actuators, such as vibration motors found on gamepad controllers, and potentially other devices that provide haptic feedback.

So it feels inappropriate the continue any evolution of the Vibration API as in DAS (beyond errata, editorial fixes) as haptics are not in scope of the DAS Working Group.

I would instead encourage DAS members (of which most, if not all, are members or WebApps), to come work with Web Apps WG on haptics instead. WebApps has a broader set of members and potential implementers than DAP, so it makes more sense to do the Work in Web Apps (and possibly obsolote Vibration if WebApps defines something better).

[anssiko]

@reillyeon I'm happy to provide such a manually-curated implementation report. However, I need to get my hands on various mobile devices to test with. If WG participants have appropriate devices I welcome contributions. I'm interested in devices capable of running these implementations: https://caniuse.com/vibration

For now we have updated the specification to point to https://wpt.live/vibration/ and https://wpt.fyi/results/vibration for test suite and implementation report respectively.

@marcoscaceres, DAS WG is chartered to maintain the Vibration API. Does that address your concern?

[marcoscaceres]

@anssiko wrote:

I'm interested in devices capable of running these implementations: https://caniuse.com/vibration

Before you do that, the WG MUST get clarification from the W3C is Chromium-only implementations (see https://github.com/w3c/vibration/issues/33#issuecomment-2121648150) count as independent implementations. Otherwise, you'll be wasting your and time writing a report that doesn't meet the process requirements.

I again remind you that, as per "6.3.2. Implementation Experience" it's the Team, not Editor or the WG or Chair, that makes the determination about what counts as an implementation.

Please get clarification from @plehegar and @himorin before proceeding with the implementation of report. If they say that Chromium-only implementations count, then I don't have a case for my objection on this matter.

To be clear, we are taking about this only being supported on Chromium Engine browsers:

• Chrome: Chromium
• Edge: Chromium
• Opera: Chromium
• Chrome for Android: Chromium
• Samsung Internet: Chromium
• Opera Mobile: Chromium
• UC Browser for Android: Chromium
• QQ Browser: Chromium
• Baidu Browser: Chromium

Further, the report need to be clear on (noting things I have emphasized) with the Team (not Editor or the WG or Chair) assuring the following:

• is each feature of the current specification implemented, and how is this demonstrated?
• are there independent interoperable implementations of the current specification?
• are there implementations created by people other than the authors of the specification?
• are implementations publicly deployed?
• is there implementation experience at all levels of the specification’s ecosystem (authoring, consuming, publishing…)? (e.g., https://chromestatus.com/metrics/feature/timeline/popularity/850)
• are there reports of difficulties or problems with implementation?

In particular, the report should note things like why certain implementations don't work and implementer feedback (and particular, the feature being remove from engines like WebKit).

@marcoscaceres, DAS WG is chartered to maintain the Vibration API. Does that address your concern?

Depends on what "maintain" means to the WG.

If maintain means errata, then that is fine, as it only applies to "error that can be resolved by one or more changes in classes 1-3 of section § 6.2.3 Classes of Changes."

That is:

1. No changes to text content
2. Changes that do not functionally affect interpretation of the document
3. Other changes that do not add new features

If maintain means working on new features, then that remains a concern.

In https://github.com/w3c/vibration/issues/33#issuecomment-2120464362, above @anssiko said:

With time, it might be that the baseline LCD will move so that we can update this API to consider new features. One of the possible such features under consideration is strength control https://github.com/w3c/vibration/issues/17 that might be soon about to reach the level it could be considered. Contributions welcome in this area too from interested folks.

That seems to imply (and explicitly encourage) feature development of something that is outside the scope of the working group.

If that's the case, my formal objection stands.

Hope that helps clarify things.

[anssiko]

About the implementation experience:

From what I see, QQ Browser uses a variant of WebKit and UC Browser "the unique self-developed U4 engine".

Per https://caniuse.com/vibration both QQ Browser and UC Browser support the Vibration API and per https://gs.statcounter.com/browser-market-share/all/china these two are the most popular Chinese browsers with 8.59% and 8.27% market share in China respectively as of May 2024 across all platforms.

About the maintenance question:

The section on maintenance includes the following language:

The Working Group will maintain errata and new editions, as necessary, for the Geolocation API, Vibration API, and HTML Media Capture W3C Recommendations.

By DAS WG convention, we list in this section specifications that have reached the Recommendation maturity stage and revising a Recommendation defined by the W3C Process applies to these deliverables.

What comes to the strength control feature #17, I'd like to note there are open-source projects in this space, e.g. Haptic Vibration Pattern Generator that generates complex haptic vibrations via navigator.vibrate(). I updated that issue with a pointer for consideration.

[marcoscaceres]

About the implementation experience:

Right, but one still needs to check if QQ actually vibrates, and that should be weighed against all the other feedback given of why other implementations pulled support (i.e., the wide review).

As the questions from the Process I highlighted in https://github.com/w3c/vibration/issues/33#issuecomment-2144126988 note, it's not just about how widely deployed it is, but if the W3C should be "Recommending" something that numerous industry players have deemed harmful (i.e., the "are there reports of difficulties or problems with implementation?").

Consider: all browsers do pop-ups (let's say 100%), that doesn't mean popups are a great idea and the W3C should be recommending them. Just because something is deployed doesn't mean it's not being used in a way that could annoy users (i.e., see again what I said about "lying with statics", which you either deliberately or inadvertently continue to do). Randomly quoting big numbers doesn't make for a strong case, because it might just mean that a bunch of users are just getting annoyingly buzzed in China. Also doesn't prove anything about the API actually working - as I proved below (It's not supported in iOS, of course).

Particularly for a contentious API like this one, a more persuasive story would be: "N browsers have implemented it and we have confirmed it working, and it's being effectively used in this manner [details here]. Example sites: a, b,... and z."

By DAS WG convention, we list in this section specifications that have reached the Recommendation maturity stage and revising a Recommendation defined by the W3C Process applies to these deliverables.

Right, but did you actually read the section?

Unlike Geolocation, for instance, the Vibration spec CANNOT receive candidate connections or candidate additions. This is because it was never "explicitly identified as allowing new features using candidate additions."

Thus, you can only make "Markup Changes" or "Editorial Changes".

What comes to the strength control feature https://github.com/w3c/vibration/issues/17, I'd like to note there are open-source projects in this space, e.g. Haptic Vibration Pattern Generator that generates complex haptic vibrations via navigator.vibrate(). I updated that issue with a pointer for consideration.

Although fascinating, I'm not sure why that matters? We are discussing what the Working Group can and cannot do.

The objection is still that further development of haptics are not in scope of the working group, because they are not listed as such.

And, given the feedback, if the W3C should be "recommending" this API at all.

[marcoscaceres]

Checked QQ on iOS. It does not vibrate. The API is not implemented:

[marcoscaceres]

About UC Browser, it's a Chromium browser according to Wikipedia. That calls into the question the marketing claims about "the unique self-developed U4 engine" 🙄 , which sounds like total nonsense.

[marcoscaceres]

If QQ is using WebKit on Android (which I'm super skeptical about), then it's unlikely the API will work there as the code was removed from WebKit years ago. It's more likely QQ is using a Chromium WebView on Android.

Unfortunately, I wasn't about to get into the browser itself because it requires registration and an invite. I've reached out to someone in China to check if it actually works.

[siusin]

From what I see, QQ Browser uses a variant of WebKit and UC Browser "the unique self-developed U4 engine".

I'm afraid the information on Wikipedia may be outdated concerning Chinese browsers. It probably refers to the period before 2013 when Chrome had not yet diverged from WebKit. According to the official websites of QQ Browser and UC Browser, both browsers are currently built on Chromium for Android.

[himorin]

just an naive and personal question, is there any good/easy way to detect error from permission request failure? I understand tests and implementation report for 2nd edition were made before permissions integrated into ecosystem, and vibration 2nd edition has not touched to be integrated with permissions, although...

[anssiko]

@siusui thanks for looking into these Chinese browsers. Where can we get reliable information about all Chinese browsers in use, their versions and features? Preferably in English. Also advice on how to test them outside China would be required to be able to produce an updated implementation report.

In the User Agents Database I see a number of engines developed by Chinese companies. I'm in particular interested in testing browsers that use these engines: T5, U2, T7, U3, X5.

[marcoscaceres]

T5, U2, T7, U3, X5.

You will find these are all Chromium. No one is developing any independent engines. However, if you want to spend your time checking, go for it.

[saschanaz]

In the User Agents Database I see a number of engines developed by Chinese companies. I'm in particular interested in testing browsers that use these engines: T5, U2, T7, U3, X5.

All of those user agent strings look very much like Chromium fork indeed.

[anssiko]

All of those user agent strings look very much like Chromium fork indeed.

Thanks for helping out. Considering Blink is a fork of WebKit this is important information for the implementation experience assessment.

More information on those engines would be required to make an informed decision. There is an informative Simplified Chinese translation of an earlier version of this API that can be helpful when reaching out.

[saschanaz]

Blink is independent because it's a hard fork with a decade of deviation and features are being completely independently implemented and maintained regardless of WebKit implementation. Without an open source repository it'll be hard to prove how much those engines are independent.

[marcoscaceres]

Considering Blink is a fork of WebKit

🤣 ... seriously @anssiko, this is getting absurd. Please tell me you are joking?

More information on those engines would be required to make an informed decision.

It's really not. You are just misdirecting in an effort to waste the Team's time by citing some random site you found that has a bunch of fake/nonsense "engines" listed. They are just Chromium.

There is an informative Simplified Chinese translation of an earlier version of this API that can be helpful when reaching out.

Reaching out to who? @siusin (from the W3C Team, who is in China) already reached out to people and is in China and told you they are Chromium. Just accept you are wrong so we can move on.

[saschanaz]

I too sincerely disagree with what Anssi is arguing, and I agree that we shouldn't consume too much time this way, but I don't think it's a good idea to blame anyone here.

I want to point out that this is not the first time within W3C that people disagreed what is independent implementation and what is not. Do we have a normative document about what engines W3C think are independent so that we can refer to that for this kind of discussion?

[anssiko]

@saschanaz asked:

I want to point out that this is not the first time within W3C that people disagreed what is independent implementation and what is not. Do we have a normative document about what engines W3C think are independent so that we can refer to that for this kind of discussion?

This topic was discussed in https://github.com/w3c/AB-public/issues/120

Inviting @cwilso to this discussion. (Sorry in advance for pulling you into this one, but you seem to be on top of the relevant AB discussion.)

[reillyeon]

I think we can safely accept the following as facts:

1. There have been two independent implementations of this API: one in the Gecko engine (which has since been removed) and one in WebKit (which was removed from WebKit after the Blink fork). That leaves one remaining implementation in Blink.
2. While there are many Chromium-based browsers which enable this API, they all inherit that original WebKit implementation.
3. The Gecko and WebKit implementations were (at the time they co-existed) interoperable.

Additional implementations would have to come from an engine not derived from Gecko or WebKit, or an implementation in Gecko or WebKit that was built after the original implementations in those engines were removed. We haven't been presented with any evidence of these scenarios.

Let's avoid drawing conclusions based on those facts. All I asked for was a report on what implementations exist and I believe we have gathered sufficient information on that topic for @anssiko to produce it.

[marcoscaceres]

Perfect! Thanks @reillyeon 🙏

Though perhaps someone can work with @anssiko that has some experience in this area and can provide some oversight? The number of times I've had to refute the misuse of statics, call out bogus web sites, and call out the fact that no actual testing was done (i.e., check that it actually vibrates) doesn't fill me with confidence.

[reillyeon]

I will be reviewing the PR for the implementation report.

[anssiko]

I want to bring to this discussion the following consideration. Perhaps @cwilso and the AB folks have already discussed this, in which case I'm happy to redirect this to a more appropriate place. This comment was inspired by @saschanaz's important question on what is an independent implementation.

Also, hopefully piggy-packing on this issue doesn't offend anyone. This case at hand just happens to make this consideration more concrete. Let's go:

For certain hardware-centric features, the majority of the implementation (say, in terms of lines of code, or in terms of complexity) is on the layers below the rendering engine. Think of this stack: application, middleware, libraries, OS drivers, OS kernel, OS HAL, firmware and hardware. To simplify, rendering engine is the application, the topmost layer. This topmost layer can be a thin wrapper from a perspective of a particular hardware feature. On all of these layers we can find independent implementations. However, when working on software only features (things we can test end-to-end without specific hardware), we are used to look for independent implementations on the topmost layer only.

After reading the implementation experience definition and the latest AB discussion https://github.com/w3c/AB-public/issues/120 I'm wondering whether the independence of the layers below the topmost layer is a more substantial consideration for hardware-centric features? What if the topmost layer is the same, while all the layers underneath have multiple independent implementations, and we can demonstrate interoperability? What if we flip this: the topmost layer has independent implementations, but the layers below that, that make up the majority of the implementation, are the same?

To make the latter case more concrete, an interesting case study is the WebRTC API. For that API, there are multiple independent rendering engine implementations, but all are using the same open-source library underneath that is the largest part of all the end-to-end implementation. This specification is a Recommendation so it has passed the implementation experience test. Does the same hold if we have the same topmost layer, but demonstrate independence on the layers below, including interoperability?

I was unable to find a good answer to @saschanaz's question. That started to bug me, so I wanted to share this thought. Perhaps the answer is this will be considered on a case by case basis. Thanks for reading.

[marcoscaceres]

Could we please move this discussion elsewhere, as it's off-topic for this thread? @anssiko, let's try to stay focused and avoid any further delays. Comparing .vibrate() to WebRTC doesn't seem appropriate.

For browser APIs, we rely on Gecko, Chromium, and WebKit as our reference points. This is why we have initiatives like Interop 2024. The definition of "interop" is clear. If you have questions, referring to the Interop project should provide the answers.

@reillyeon, would you like me to draft the report? It seems like progress will just keep getting stalled, and we need to keep things moving forward.

@anssiko, I encourage you to review the available resources (e.g., a Google search, asking ChatGTP) to find the information you need rather than waiting on others to do it for you.

[marcoscaceres]

Also, go and look at your own working group minutes how many times Mozilla and WebKit get mentioned and questions around what WebKit and Mozilla are doing: https://www.w3.org/2023/09/14-dap-minutes.html#t16

It's pretty clear that DAS, and you, know exactly what "Interop" is. Stop pretending this is suddenly some grand philosophical question you've stumbled across for the AB to ponder, and that "if you squint just right...". It's extremely disingenuous and slimy.

[marcoscaceres]

@reillyeon, here you go. Please feel to use as the basis.

Implementation Report for the W3C's Vibration API

Date: June 8, 2024

Test suite

The tests were conducted on 8 June 2024 using the test cases from https://wpt.live/vibration/. The testing devices included a Pixel 7 running Android 14 for Chrome for Android and Firefox for Android, and an iPhone 15 running iOS 17.4.1 for Safari.

Manual Tests

Test	Chrome for Android (125.0.6422, Blink)	Firefox for Android (126.0.1, Gecko)	Safari on iOS 17.4.1 (WebKit)
cancel-when-hidden-manual.html	Pass	Fail	Fail
cancel-with-0-manual.html	Pass	Fail	Fail
cancel-with-array-0-manual.html	Pass	Fail	Fail
cancel-with-empty-array-manual.html	Pass	Fail	Fail
cancel-with-new-manual.html	Pass	Fail	Fail
pattern-array-extra-manual.html	Pass	Fail	Fail
pattern-array-manual.html	Pass	Fail	Fail
pattern-array-with-0-manual.html	Pass	Fail	Fail
simple-array-manual.html	Pass	Fail	Fail
simple-scalar-manual.html	Pass	Fail	Fail
Pass/Fail Ratio	10/10	0/10	0/10

Automated Tests

Test	Chrome for Android (125.0.6422, Blink)	Firefox for Android (126.0.1, Gecko)	Safari on iOS 17.4.1 (WebKit)
api-is-present.html	Pass	Pass	Fail
idlharness.window.js	Pass	Pass	Fail
invalid-values.html	Pass	Pass	Fail
silent-ignore.html	Pass	Pass	Fail
Pass/Fail Ratio	4/4	4/4	0/4

W3C Process questions relating to implementation experience

Please see implementation experience.

Is each feature of the current specification implemented, and how is this demonstrated?

• Basic API features are implemented in Chrome for Android (Blink) and Firefox for Android (Gecko), as shown by the automated tests. All manual tests failed in Firefox for Android (Gecko) and Safari on iOS (WebKit), showing incomplete implementation in Firefox for Android and no implementation in Safari on iOS.

Are there independent interoperable implementations of the current specification?

• No, interoperability is not achieved. Manual tests fail on Firefox for Android (Gecko) and Safari on iOS (WebKit), and pass solely on Chrome for Android (Blink).

Are there implementations created by people other than the authors of the specification?

• Yes, implementations exist by independent developers. For Chromium (Blink), see NavigatorVibration.cpp. For Gecko, see Navigator.cpp, specifically Navigator::Vibrate.

Are implementations publicly deployed?

• Yes, Chrome for Android (Blink) and Firefox for Android (Gecko) are publicly deployed. Safari on iOS (WebKit) does not implement the API.

Is there implementation experience at all levels of the specification’s ecosystem (authoring, consuming, publishing…)?

• Chrome's use counter for navigator.vibrate() shows usage between 0.06% and 0.08% from 2022-2024 with clearly demonstrable attempt as misuse. The provided list of 148 URLs from Chrome's use counter mostly includes online pharmacy sites, adult websites, link farms, and low-quality sites. Sites showing real use of the API are difficult to find, indicating low value. Feature detection is frequent in code repositories (see GitHub code search).

Are there reports of difficulties or problems with implementation?

• Yes, there are significant issues. All manual tests fail on Firefox for Android (Gecko) and Safari on iOS (WebKit). Safari on iOS also fails all automated tests, indicating no implementation and support for the Vibration API on iOS.
• The API was removed from WebKit on May 11, 2017 (see changeset 216696) over concerns of user annoyance and API misuse.
• In Gecko, the API does nothing in Firefox for Android due to a missing permission, with concerns about user annoyance and misuse cited as reasons for disfavor (see GitHub issue).
• For Chromium, Google had to put mitigations in place to prevent sites from using the API without user activation: "Calls to navigator.vibrate will immediately return 'false' if user hasn't tapped on the frame or any embedded frame yet. The Vibrate API is being abused by malicious sites. This extends what we do for cross-origin iframes to all frames including top-level page."
• The aforementioned mitigation is constituently having to be appleid to most sites listed , as part of Chrome's use counter, showing there's was, and still still, wide-spread abuse of this API on the Web.

[marcoscaceres]

@reillyeon, it would be good to amend with the following misuse cases:

• Trying to turn a phone into a gamepad: using Gamepad API would be better.
• Being used to emulate Notifications. The notifications API itself provides vibrations. Unlike with this API, the user is in control as to if the device vibrates (through settings at the OS or browser level). This prevents user annoyance that the Vibration API can't - while also being privacy preserving. I'll also note that Mozilla has disabled vibrate on notifications regardless on all platforms, to prevent user annoyance. Setting vibration on notifications in iOS is not supported at all.

[egirard]

@marcoscaceres : "Feature detection is frequent in code repositories (see GitHub code search)."

The link you've provided contains code that detects then uses the API. This pattern is necessary due to lack of implementation, not because of non-use.

Can you provide more meaningful evidence for your statement: "Chrome's use counter for navigator.vibrate() shows usage between 0.06% and 0.08% from 2022-2024, primarily for feature detection."

[marcoscaceres]

The link you've provided contains code that detects then uses the API. This pattern is necessary due to lack of implementation, not because of non-use.

This is true. But it's also being used for feature detection. There are examples of usage, but those should be looked at in the context of replicating notifications, replicating a gamepad, or if they would be blocked by interactions started without a gesture.

I added Chrome's abuse mitigation details to the report.

Can you provide more meaningful evidence for your statement:

Actually, all the case do the feature detection, but do then then try misuse the API (all cases prevented by Chrome):

• https://ajhales.co.uk
• https://acidentedetrabalho.advogadotrabalhistamf.com.br/
• https://www.infirmier.cloud/
  • https://www.kloesterl-apotheke.de/
  • https://www.centersvet.com/
  • https://m.uwin777.bet/
  • https://shop.pluspunkt-apotheke-schwedt.de/
  • https://www.centrsvet.by/
  • https://www.bapoo.de/

And so on... basically check any of the sites and they all get blocked from using the API by Chrome. You will see:

There's also things like:

• https://warelawfirm.com/ :

  has disabled it self from pretending to a notification.

And just silly uses:

• https://itradeit.in/ - where tapping anywhere causes a vibration.

And straight up abuse cases like:

• https://www.satcomglobal.com/
• https://www.wrel.de/

God... the more one looks, the worst it gets with this thing...

[marcoscaceres]

@egirard, do you want to check a couple more? I honestly can't find any in the Google's set that are not problematic or abuse cases. Thankfully Chrome just blocks like 99% of them.

[marcoscaceres]

This one is fun too: https://wincard.thecashmint.com/?vibrate=123

It tried to vibrate through a URL parameter when everything load😹... and get blocked. Oh, no, it's on an interval! 🙃

Anyway, I hope this report helps clarify the state of the Vibration API on the open web:

• No actual interoperability, as demonstrated by the report.
• Two out of three engines have pulled support over concerns of misuse.
• Evidence of abuse and misuse at scale.
• Chrome has implemented its own abuse mitigation due to high levels of misuse.
• The specification lacks maintenance, with deficiencies filed as issues since 2016.

It's truly astounding that this API remains with a "W3C Recommendation" status given all the stuff that I've presented above - and it's shocking, disheartening, and absolutely shameful that, despite overwhelming evidence, some here are seriously advocating that it should retain the "Recommendation" status.

[egirard]

@egirard, do you want to check a couple more? I honestly can't find any in the Google's set that are not problematic or abuse cases. Thankfully Chrome just blocks like 99% of them.

Thanks for digging deeper. Chrome does do a reasonable job of mitigating / blocking "troublesome" vibration calls. And the usage of this API remains extremely low.

[egirard]

In spite of the prevailing opinion, there remains a meaningful use case for haptics. For example, native apps have access to haptics in ios, macOS, android, and windows.

I don't have insight into how actively these APIs are used, but there are many examples of haptic feedback being used effectively in native apps. It would be unfortunate to limit web developers access.

[scheib]

Yes, there are valid use cases. I was just discussing a partner's needs which does use vibration. They established a large business as a web app, and I don't think we should force them away.

Also, there is abuse, which has been mitigated and could be addressed further if necessary.

While some browsers may choose not to expose the feature I don't personally see the issue with this specification existing in the WG.

Marcos, your contributions are so valuable to so many specifications in need of material improvement. When you work on those I'm always grateful.

[reillyeon]

Trying to turn a phone into a gamepad: using Gamepad API would be better.

@marcoscaceres, can you clarify why you think this is misuse? It is a common pattern in mobile games to use on-screen controls to emulate a gamepad, and haptics are a reasonable part of this. To use the Gamepad API for this would be strange since a mobile device would only provide the haptic portion of the Gamepad API.