I have a working patch, but not sure catching resume() and suspend() are meaningful. That's user-initiated function call, so it can be caught from JS code side.

With that said, I implemented something similar to Canvas Context. That is much more similar to AudioContext rather than Media stuffs.

CL: https://chromium-review.googlesource.com/c/chromium/src/+/1089200

Thanks Hongchan for implementing this. I'm not sure how to set breakpoints on native functions like AudioContext.suspend() from the Inspector, so these are greatly appreciated for debugging purposes.

SGTM. I'll try to add break points in HTMLAudioElement once I land the CL above.

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

commit 5cc93793d9819f9b0d9e6fde47cdeb8e9c481ae4
Author: Hongchan Choi <hongchan@chromium.org>
Date: Mon Jun 18 22:24:36 2018

Add EventListenerBreakPoints for AudioContext operation

This CL adds EventListenerBreakPoints for the AudioContext constructor,
AudioContext.close(), AudioContext.resume() and AudioContext.suspend().

Bug: 848473
Change-Id: Ifbbccfd1e21dc8b5b444993c7143e869a56d7e6c
Reviewed-on: https://chromium-review.googlesource.com/1089200
Commit-Queue: Hongchan Choi <hongchan@chromium.org>
Reviewed-by: Raymond Toy <rtoy@chromium.org>
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568197}
[add] https://crrev.com/5cc93793d9819f9b0d9e6fde47cdeb8e9c481ae4/third_party/WebKit/LayoutTests/http/tests/devtools/sources/debugger-breakpoints/event-listener-breakpoints-webaudio-expected.txt
[add] https://crrev.com/5cc93793d9819f9b0d9e6fde47cdeb8e9c481ae4/third_party/WebKit/LayoutTests/http/tests/devtools/sources/debugger-breakpoints/event-listener-breakpoints-webaudio.js
[modify] https://crrev.com/5cc93793d9819f9b0d9e6fde47cdeb8e9c481ae4/third_party/blink/renderer/core/inspector/inspector_dom_debugger_agent.cc
[modify] https://crrev.com/5cc93793d9819f9b0d9e6fde47cdeb8e9c481ae4/third_party/blink/renderer/core/inspector/inspector_dom_debugger_agent.h
[modify] https://crrev.com/5cc93793d9819f9b0d9e6fde47cdeb8e9c481ae4/third_party/blink/renderer/core/probe/CoreProbes.json5
[modify] https://crrev.com/5cc93793d9819f9b0d9e6fde47cdeb8e9c481ae4/third_party/blink/renderer/core/probe/CoreProbes.pidl
[modify] https://crrev.com/5cc93793d9819f9b0d9e6fde47cdeb8e9c481ae4/third_party/blink/renderer/devtools/front_end/sdk/DOMDebuggerModel.js
[modify] https://crrev.com/5cc93793d9819f9b0d9e6fde47cdeb8e9c481ae4/third_party/blink/renderer/modules/webaudio/audio_context.cc

The item 2) and 3) are fixed by #6.

Thanks Hongchan. Verified with https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Mac/568724/ and https://www.shadertoy.com/view/Xds3Rr that the new event listener for the WebAudio constructor is working -- (2) above.

It turns out that this sample doesn't suspend and resume the AudioContext, so wasn't able to verify (3).

The existing Media EventListener breakpoints aren't working for this sample. To confirm, please do the following:

1) Open the sample
2) Click play/pause a couple of times to get the audio to start playing
3) Open DevTools
4) Set Event Listener Breakpoints on Media, play/pause
5) Click the play/pause button a few times; verify that these breakpoints are never hit
6) In Sources, go into www.shadertoy.com , then js, then effect.js
7) Go to line 626 and 660
8) Set breakpoints on "inp.audio.pause()" and "inp.audio.play()"
9) Verify these breakpoint is hit while clicking the play/pause button on the ShaderToy Page

kozy@ or caseq@, could you please help figure out why these aren't getting hit? The HTMLAudioElement is instantiated via "new Audio()" -- which it would also be helpful to have an Event Listener breakpoint for per (1) in the bug description.

Thanks.

Confirmed with kbr@ that this bug is still present.

Changing to type=bug temporarily. We can change it back to Feature once the problem in #8 above is fixed.

I think that it is not a bug. Existing 'media > play' event listener breakpoint emits pause when 'play' event listener is called. So if you add listener for inp.audio by executing something like 'inp.audio.onplay = msg => console.log(msg)', debugger will emit pause as soon as listener started.

We can have better UI to avoid this kind of a confusion and we can separate breakpoint for .play call.

Thanks for the analysis. That's really confusing to me because other "event listener breakpoints" like "Canvas > Create canvas context" have no associated events, but break when HTMLCanvasElement.getContext() is called.

Could you please consider this a feature then, and please add to the Media event listener breakpoints:
 1) "Create MediaElement" - breaks upon HTMLMediaElement constructor (including HTMLAudioElement - so we can stop upon "new Audio()")
 2) "Play MediaElement"
 3) "Pause MediaElement"

and any others you think would be useful for debugging the behavior of https://www.shadertoy.com/view/Xds3Rr ? Thanks very much.