If that's of any help, this also happens to me on Chrome Version 64.0.3245.0 (Build officiel) canary (64 bits) on Mac OS 10.12.1. with the "Hello AudioWorklet!" demo.

I wasn't able to reproduce this because I was launching Canary with the command line option instead of changing a flag in "chrome://flags".

The command line option:
--enable-blink-features=Worklet,AudioWorklet

With this option, everything runs fine. I will try to investigate further, it doesn't seem to be an issue from WebAudio.

I can't reproduce this anymore on the latest Canary:
Version 64.0.3271.0 (Official Build) canary (64-bit)

Tested 64.0.3272.0 (Build officiel) canary (64 bits) on Mac OS 10.12.1.

The flag chrome://flags/#enable-experimental-web-platform-features no longer enables AudioWorklet (tried disabling, rebooting, reenabling and rebooting). AudioWorkletNode exists but window.audioWorklet is undefined.

Is the page served via HTTPS? All the worklets now work only on the secure
context, meaning HTTPS is mandatory.

Yes, I tested it on the "Hello AudioWorklet!" demo ( https://googlechromelabs.github.io/web-audio-samples/audio-worklet/basic/hello-audio-worklet.html ).

I tried to use the command line flag instead of the "chrome://flags" page since I figured the issue might be specific to the the flags in this page. When trying to launch Canary in command line with "--enable-blink-features=Worklet,AudioWorklet", it displays a notice stating "You are using an unsupported command-line flag: --enable-blink-features=Worklet,AudioWorklet. Stability and security will suffer" (the equivalent in French). I used the following command : open "Google Chrome Canary.app" --args --enable-blink-features=Worklet,AudioWorklet

That seems like a new bug on how SecureContext works. Let me reproduce it
on my machine and file a bug against Worklet infra if that happens.

Thanks for reporting it!

re #10: The problem is confirmed. See the  issue 786750 .

This issue does not happen anymore. Perhaps the devtool reporting proxy's behavior has been fixed.

The original issue (browser tab inconsistently hanging when using AudioWorklet with the devtools open on Mac) is still happening on my end with Version 65.0.3295.0 (Build officiel) canary (64 bits).

 Issue 795792  has been merged into this issue.

kevin.chapelier@

Are you still experiencing this issue?

FWIW I am the reporter of the duplicate  Issue 795792  and it is still happening.

Version 66.0.3346.0 (Official Build) canary (64-bit)
Enabled using chrome://flags/#enable-experimental-web-platform-features

Re #17:

Please try with "--enable-blink-features=AudioWorklet" and see if the problem persists. I locally confirmed the hang does not happen when you use AudioWorklet only.

The flag you're using enables the entire package of experimental features in Blink, which makes it really difficult to triage.

Confirmed the problem goes away if I switch to "--enable-blink-features=AudioWorklet".

Sorry for the delay. Just like kpreid.s.., I cannot reproduce the issue anymore either on Version 66.0.3348.0 (Official Build) canary (64-bit) on Mac (unless the enable-experimental-web-platform-features flag is enabled). Tested the hello-world page relying on the origin-trail meta as well as a local script relying on the command-line argument.

Thanks for confirmation. I'll try to find out the offending component.

I just tried to repro again, but could not reproduce.

* 66.0.3347.0 (debug)
 - Experimental Web Platform feature flag enabled.
 - No hang

* 66.0.3348.0 (canary)
 - Experimental Web Platform feature flag enabled.
 - No hang

I will revisit this in few days.

The NextAction date has arrived: 2018-02-19

kpreid.switchb.org@
kevin.chapelier@

I just tested with Version 66.0.3350.0 (Official Build) canary (64-bit) on MacOS. The tab does not hang. (with flag, not the command line option)

Can you re-test the repro case?

Can still reproduce intermittently on 66.0.3350.0

Sorry, that was a little too brief.

Can still reproduce intermittently on 66.0.3350.0 with enable-experimental-web-platform-features and no command line flags.

I reproduced it with both my original broken code, my debugged code, and https://googlechromelabs.github.io/web-audio-samples/audio-worklet/basic/hello-audio-worklet.html — but it took ~10 reloads rather than just one before it hung on that page.

kpreid.switchb.org@

Please try with the latest Canary (67.0.3370.0). I believe this issue is fixed or not relevant anymore.

On 67.0.3370.0:

No issues noticed on https://googlechromelabs.github.io/web-audio-samples/audio-worklet/basic/hello-audio-worklet.html

On my more complex app, I am getting "Aw, Snap" on reload at a rate of ~5-10%, but the tab does not become wedged in the same fashion. With (--enable-logging -v 1) I see the following messages only when there is an Aw Snap:

[84967:43795:0314/174626.737213:WARNING:audio_sync_reader.cc(193)] AudioSyncReader::Read timed out, audio glitch count=10
[84967:43795:0314/174626.795273:WARNING:audio_sync_reader.cc(193)] AudioSyncReader::Read timed out, audio glitch count=20
[84967:43795:0314/174626.827093:WARNING:audio_sync_reader.cc(175)] ASR: No room in socket buffer.: Broken pipe (32)

The third message is not always present. Also, the Aw Snap occurs very quickly after Cmd-R; I suspect it is caused by the previous page state, not the newly loading one.

I'll see about a shareable repro, but should I file a separate issue for this? I found other mentions of these messages, but they all seem to be non-worklet or specifically WebRTC.

kpreid.switchb.org@

It would be great if you can provide a repro case for the crash. Unless we have a repro case to look at, opening a new bug is unnecessary.

Filed issue 822725 for that.

AudioWorklet demos are not crashing anymore, so I will close this. The other crash is being investigated in the issue 822725.

Thanks for your help, kpreid.switchb.org@!