navigator.vibrate requires user gesture even in PWAs
Reported by
kylemacf...@gmail.com,
Dec 21 2017
|
|||||||
Issue descriptionApplication version: 63.0.3239.111 Operating system: Android 7.1.1 Steps to reproduce: (1) Call window.navigator.vibrate before any user interaction in a PWA Expected result: The phone should vibrate. Especially since PWAs already have permission to play audio and video and can vibrate the phone via service worker notifications. Actual result: It will be blocked with the error: [Intervention] Blocked call to navigator.vibrate because user hasn't tapped on the frame or any embedded frame yet: https://www.chromestatus.com/feature/5644273861001216.
,
Dec 22 2017
+ojan for interventions and triaging
,
Dec 22 2017
Sorry but it's a private app so can't be linked to.
,
Dec 22 2017
Thank you for providing more feedback. Adding requester "pnangunoori@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 22 2017
owencm: Are you the right person to own figuring this out? We allow autoplay video if you've been added to homescreen. It makes sense to me that all of the persistent, you-only-needed-a-gesture-at-some-point-in-the-life-of-the-page features should get auto-granted for homescreen apps. Conceptually, you can think of clicking on the homescreen icon as a user gesture even. WDYT? Basically, anything that uses the HasBeenActivated bit: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/frame/Frame.h?type=cs&sq=package:chromium&l=150 I can think of one exception, which is the eliding from history of pages that didn't have a gesture or sufficient time on the page. But, I don't think that's a problem for PWAs. It should be a strictly better user experience in nearly all cases. See also related discussion: https://github.com/WICG/interventions/issues/47#issuecomment-283700531
,
Dec 22 2017
,
Dec 30 2017
A general policy for these topics is captured here: https://docs.google.com/document/d/19KtJH_MtgjFQD-1wUurdY3C4h62_AJnf1a9g3lD1Tt4/edit# The key part is: ``` If the user goes through a low friction “add to home screen” flow that is more like adding a bookmark, then we should simply treat it as a site with high user engagement and may skip may restriction such as user gesture if the “add” flow is considered a stronger “gesture”. ``` Hence I see no policy issue with enabling vibrate without a gesture for a site the user has pinned to home screen.
,
Jan 4 2018
Making vibration similar to autoplay looks like a logical solution. In fact, all features that require sticky user gestures (i.e. rely on HasBeenActivated bit) should be enabled for PWA. owencm@/ojan@: I think we need to clarify the distinction between "adding to home screen without ever interacting with the page" vs actually interacting with the page (through either "regular" user gestures on the page or even clicking on the home screen icon). This looks analogous to installing a native app vs running the app. mlamouri@: Does our autoplay behavior distinguish between these two cases?
,
Jan 5 2018
I'm not sure what the two cases are. In Chrome Android, when a website is run from a Web APK, the Manifest's scope will be allowed to autoplay. At the moment, this mechanism is specific to autoplay but we could make this "gesture-free" instead and use it for both vibrations and autoplay.
,
Feb 6 2018
@rajagop How are you scanning a QR code without user interaction? Presumably you are either using the camera which requires user interaction to open or a Bluetooth or USB scanner which behaves as a keyboard so counts as user interaction.
,
May 8 2018
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by pnangunoori@chromium.org
, Dec 22 2017Labels: Needs-triage-Mobile Triaged-Mobile Needs-Feedback