The issue seems to be related to OS-android. Hence, adding appropriate OS label.

Thanks...!!

This is work as intended since touchstart is not considered as user gesture any more (eg., mentioned here: https://www.chromestatus.com/feature/6131337345892352), but it works with the click event (try onclick).

+rbyers@chromium.org, ojan@chromium.org as FYI.

What if the first action a user takes is a long press on an element?  I'm trying to make the site act as much like an app as possible.

In that case, have you tried touchend? It should work according to https://www.chromestatus.com/feature/6131337345892352.

Yes, I have tried touchend, but the interaction people expect is not for the long press animation to start at the end of a touch but a second or so after long pressing.  For example, try holding down your finger on the android home screen.  The reaction from long pressing happens before you let go.  Every app and even iOS reacts the same way.

Can you explain more about the use case that you have in mind? Like what kind of website you are building (eg., games or accessibility)? Why long press is preferred for vibrate triggering (instead of click)? 

+mustaq@chromium.org, who is working on user gesture refinement.

When uploading a file I have a single circular + button in the bottom right corner.  By default it will let you upload files, however I also want it to let you take a picture.  Instead of forcing people to tap the + button and then tap again to select the camera option, I'm trying to make it simpler... where you can long press the + button to select a different upload type (and it becomes the new default).

Another feature I was planning on adding is long pressing a photo to give extra options (such as to delete it). 

Thanks redkatana1@ for the explanation, but you didn't mention why vibrate is necessary and how it helps in your use case.

I'm not sure if I understand your question.  Isn't it the standard for long press action to be accompanied with a vibration?  Would you like me to provide examples of how apps and even the Android OS reacts to a user's long-press action and how it's accompanied by a vibration effect?  (Like, long pressing the quick actions in the notification tray is accompanied by a vibration)

If you're emphasizing the word "necessary", well then I'm not sure if you could argue anything is really necessary.  I'm just trying to provide an expected experience from a user action on a webpage - one that is globally used in every mobile device and OS.

I think the source of confusion here is the "touchstart" event: Android vibration happens only after a certain time, as if when the system has detected a long press (but not release).

To me, it seems like the "contextmenu" event could possibly be considered a user activation (or "user gesture") to solve your use case.  I am not sure at this moment why this event was excluded for so many years.  Anyone has any clue?

Thanks redkatana1@ for the explanation. I guess I don't use long press much on my phone.

Adding either the "contextmenu" event or "long press for 1-2 seconds" as user gesture sounds good to me for this use case.

>> why this event was excluded for so many years.  Anyone has any clue?
I guess the use case hasn't been come up quite often for mobile web?

I was wondering about "contextmenu" event on desktop (on right click) :(

This quarter we are planning to start working the set of events that "define" a user activation.  Let's discuss it in Issue 826293.

redkatana1@: to set the expectations right, Issue 826293 is going to be a tricky one for us since it would affect ~30 different APIs in Chrome (vibrate is just one of them).  So don't expect a solution soon!

We agreed that "touchstart" is not the right place to vibrate anyways, so let's leave this bug as "WontFix".

I did some testing and it appears as though adding contextmenu as a "user gesture" should be adequate for my use cases.

Thanks for confirming redkatana1@.

redkatana1@, good news: we just landed a change to support 'contextmenu' events, will be available in Chrome 68 ( Issue 836401 ).

Thank you! :)