Unable to reproduce this issue on Mac 10.12.4 with chrome #57.0.2987.113 & #60.0.3079

These are the steps followed.
1. Launched chrome and navigated to given "index.html" file
2. Opened dev tools, clicked on "device toggle toolbar" and selected an android device
3. On the mobile device, clicked on the "Click me to play audio!"

Observed that audio is playing as expected.

bruno@ could you please confirm whether this issue exists on Mac OS or android device???

Thank You...

I would expect this to be on Android and related to autoplay. Bruno, does this used to work?

+rbyers@ because this could be related to some changes with user gesture and touch.

Sorry for not mentioning this before: on OSX it works as expected indeed, but on Android it doesn't. Using remote debugging you can see the error messages in console for the device, and audio doesn't play.

I think it used to work, but not 100% sure. Thats why I did not specify if it did or not.

I am experiencing this issue on iOS devices running 10.3.1. 

I am using an iPad Pro and audio is not starting on user gesture. 

Audio works and plays fine as expected in Safari. 

Chrome iOS Version: 57.0.2987.137 
iOS Version: 10.3.1
iOS Device: ML3K2LL

rbyers@, gentle ping :)

You need to do it in a touchend... See
https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/gesture%7Csort:relevance/blink-dev/TO_x7FRkdmw/uCrOwufTCAAJ

bru...@ why can't this just be a click event listener?

dtapu@ I want to use it in a game, where the touch sequence is more like a drag. The touchend will come a lot later than the touchstart and at a different position. So I can't use a touchend nor a click event listener.

Re #2: Please file a separate bug for iOS, that's an entirely different codebase from Android.

Yes starting audio on touchstart was disabled in Chrome 56 under  issue 611981  (context https://developers.google.com/web/updates/2016/12/chrome-56-deprecations#remove_user_gestures_from_touch_scroll).  The problem is we can't reliably tell if the user intends to just scroll the page or actually activate something.  I believe iOS has similar behavior (at least for the popup blocking case), and the HTML spec lists only touchend: https://html.spec.whatwg.org/multipage/interaction.html#triggered-by-user-activation

However if you're disabling scrolling and want to handle a drag case, you can still do it on a touchmove once the finger has moved enough.  Does that help?

> However if you're disabling scrolling and want to handle a drag case, you can still do it on a touchmove once the finger has moved enough.  Does that help?

Sorry that was incorrect.  It's the END of drag that we allow (so touchend that wasn't part of a scroll).  Still no way to do it on touchmove (as per HTML spec).

Can you give us an example UI for there starting on touchstart really provides a better experience than touchend?  Conceptually it's possible that we could relax this in the case of a 'touch-action: none' region (since we can tell that scrolling is already disabled).  Would that work for you?  It'll be non-trivial (possibly quite hard) to implement perfectly and get interoperability between browsers on though, so I think we'd need a pretty compelling use case.

Relaxing this in the case of 'touch-action: none' would solve this for me. I understand that if the gesture ultimately appears to be a scroll, that the eventlistener of the developer can be ignored, as that is most likely not what the user intended. But when there is no scrolling, not be able to do things like this is very limiting in some scenario's. Here are 3 examples that quickly come to my mind:

1. I encountered this use case when I was making a fullscreen xylophone web application (see screenshot). When the users touches one of the xylophone bars the note should play. I would also like to implement that the user can hold his finger down and swipe over all the bars and the sound of each one should play as soon the touch position reaches a new xylophone bar (instead of tapping on each one to hear the sound). In this case, I can not wait for a 'touchend' to play the sound (also 'touchmove' is not enough as the user can decide just to tap, or to tap and hold by which the sound should already have been played).

2. I can also imagine an application where you can drag user interface elements around, and wanting to playing a sound to indicate "picking something up" when the drag starts.

3. A real-time strategy game made for touch where you want to instruct in-game soldiers to go somewhere by touching and dragging in the direction you want it to go. If the soldier has to respond on the 'touchstart' with something like "What would you want me to do?" and if the gesture ends says something like "Ok".

The 'touch-action:none' solution would solve all the use cases I can imagine. 

Deleted: xylophone.png 30.1 KB

	xylophone.png 30.1 KB View Download

The new autoplay policy might help with this as only one "real" touch will be required, then touchstart will be usable.

Oh yeah moving from "is there a user gesture" to "has this frame ever had a user gesture" (as we're doing for other features like vibrate) should IMHO be an even better solution than what I was suggesting.

Worst case, that would mean when loading a game/xylophone you'd want a "Start" button the user needs to tap before audio will be enabled, but then it'll be enabled (even outside of any touches) for the duration of the frame.

bruno@ WDYT?

I think this solution would be a viable one.

Also in the case of webapps, maybe it would be possible to check if it was added and launched from the homescreen, and if it was maybe remove this 'this frame ever had a user gesture' check? Since it is an app, and the user probably wants all the intended behaviour of the app (as opposed to a website playing audio the user didn't ask for). Or has that some implications that are not desirable?

Thanks.  Ok lets call this a dupe of  issue 715049  then.

Yes there are also discussions / plans about treating the "add to homescreen" case specially.  Personally I think it makes sense to consider launching the app as an initial user gesture for the main frame (signifies user intent to interact with that origin).

 Issue 763269  has been merged into this issue.