navigator.vibrate() is supported on Android and has its own permission dialog. For bug 1572461 we would either need to support delegating this permission through the allow="" attribute or simply disallow requesting it in third-party contexts. Disabling is what we've been doing for most unusual permissions and seems reasonable here too.

James, could you confirm this is okay for mobile? Perhaps you should also review bug 1572461 as some of that likely impacts mobile too.

Yeah, just disabling seems fine to me.

https://hg.mozilla.org/mozilla-central/rev/452d9227aee6

Posted site compatibility note.

I've documented this:

Compat data updated - https://github.com/mdn/browser-compat-data/pull/5295/files

Rel note added: https://wiki.developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/72#APIs

Correct me if I'm wrong, but this patch uses {"vibration", nullptr, DelegatePolicy::ePersistDeniedCrossOrigin}, which for top-level documents ends up in https://searchfox.org/mozilla-central/rev/82c04b9cad5b98bdf682bd477f2b1e3071b004ad/extensions/permissions/PermissionDelegateHandler.cpp#290

Unless the permission is explicitly set, this fails for all origins by default, so navigator.vibrate() only works in chrome:// documents out of the box.

Fabrice, wouldn't that mean that navigator.storage.persist() also does not work (it does)?

navigator.storage.persist() works because we end up prompting the user to grant the permission with https://searchfox.org/mozilla-central/rev/1b95a0179507a4dc7d4b0c94c2df420dc1a72885/dom/quota/StorageManager.cpp#144

But navigator.vibrate() just silently returns true.

Cross posting on this same issue on Github; https://github.com/mozilla-mobile/fenix/issues/2371

As a [mostly] web dev w/ 25+ years experience, I have been waiting years for PWA's to really arrive. Put up a simple japa counter example this weekend, and it's amazing, seems finally ready for prime time. However, my favorite mobile browser and daily driver falls a bit short.

Firefox Mobile doesn't support the Vibrate API (again, as of March 9, 2022). Not due to an actual technical issue, but because it was disabled due to abuse by shady websites.

FF Mobile renders the PWA much better as a "real" app, changing the android notification bar the theme color. And of course, FF is my daily driver, and I evangelize whenever possible and would prefer to use it everywhere. However, lack of vibration API support really skews that. The fact that FF has a worse PWA developer experience than all the chromium derivatives seems wrong on many levels.

Looked at the Fenix source, after tracing several other bug reports w/ patches, but clearly, nothing for current code base. Kotlin isn't too crazy different to at least poke around. Closest hackable section I found was the QR code section, which imported the Android vibrate API, and is clearly coded to vibrate, but doesn't. So the disabling is elsewhere that I couldn't track down...

My understanding from parsing bug reports here, on Github, and reddit, is that Fenix developers disabled this due to abuse, not technical issues, and can't quite figure out how to properly surface a user permission prompt on a per site basis.

Seems like a test for "am I installed as a PWA" and "am I active" might be a workaround. This wouldn't solve the [apparently thorny] per site permission issue, but would give developers the FF powered mobile app we desire...

Reference: Is my PWA installed?
https://petelepage.com/blog/2019/07/is-my-pwa-installed/

Reference: Updated PWA mode test
https://web.dev/customize-install/#detect-launch-type