+steimel@ for triage

tristan.fraipont@ Thanks for the issue.

Tested this issue on Mac OS 10.13.3 and Windows 10 on the reported version 71.0.3551.3 and the latest Canary 71.0.3554.0 by following the below steps.

1. Launched Chrome and navigated to https://jsfiddle.net/u7zdjma1/.
2. With the 'New Media Control' flag set to default and on clicking on play button on Canary, can observe that a event is fired.
3. If the flag is set to Disabled, and on clicking on the play button, no event is fired.
4. On M-68 build, With the 'New Media Control' flag set to default and on clicking on play button, no event is fired.
Attached is the screen cast for reference.

Request you to check and confirm the actual and expected behaviors, which will help in further triaging of the issue.

Thanks..

Deleted: 884108.mp4 3.3 MB

	884108.mp4 3.3 MB View Download

@susan.boorgula@chromium.org yes I confirm this is the actual (default flag and click event fired) and expected (no event fired) behaviors.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

tristan.fraipont@ Thanks for the update.

Able to reproduce this issue on Windows 10, Mac OS 10.13.3 and Ubuntu 17.10 on the latest Stable 69.0.3497.92 and latest Canary 71.0.3554.0 as per comment #4.

Bisect Information:
===================
Good Build: 68.0.3436.0
Bad Build : 68.0.3437.0

By running the per-revision bisect script, runtime error was coming up. Hence below is the Changelog URL by running Chromium bisect.

https://chromium.googlesource.com/chromium/src/+log/cd60610885a0431bda63b46b8abedc09a9dfcc80..3267532a0e80b0aeb73ec4e72434df630bc9ce63

From the above Changelog, suspecting the below change:
Reviewed-on: https://chromium-review.googlesource.com/1067514

steimel@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner.

Thanks..

Since according to this CL note that would be by design for the exposed test-case, I updated the fiddle[1] to make the audio load a media so the click is actually not dismissed.  
I still see the same behavior even in this case.


[1]: https://jsfiddle.net/u7zdjma1/2/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1c7143323b76e2b7f0183cc58c4edd5b6ef23253

commit 1c7143323b76e2b7f0183cc58c4edd5b6ef23253
Author: Tommy Steimel <steimel@chromium.org>
Date: Sat Sep 22 01:25:14 2018

[Media Controls] Keep events in node for panel in audio controls

This CL fixes an issue where we don't keep events in node for the
audio panel.

Bug:  884108 
Change-Id: I039a606005b9be109c36f35a7bf33f4a77f951db
Reviewed-on: https://chromium-review.googlesource.com/1239006
Reviewed-by: Becca Hughes <beccahughes@chromium.org>
Commit-Queue: Tommy Steimel <steimel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593407}
[add] https://crrev.com/1c7143323b76e2b7f0183cc58c4edd5b6ef23253/third_party/WebKit/LayoutTests/media/controls/audio-element-should-not-propagate-click-events.html
[modify] https://crrev.com/1c7143323b76e2b7f0183cc58c4edd5b6ef23253/third_party/blink/renderer/modules/media_controls/elements/media_control_panel_element.cc
[modify] https://crrev.com/1c7143323b76e2b7f0183cc58c4edd5b6ef23253/third_party/blink/renderer/modules/media_controls/media_controls_impl.h

This should now be fixed. The above CL fixes the issue for audio elements, and a separate refactoring that we've recently done should have fixed the issue for video elements too. Thanks!