1. Set pref media.setsinkid.enabled true.
2. Load testcase.
3. Click "Default system output..."
4. Select removable speaker device.
5. Click "Allow".
6. Remove removable speaker device.
7. Click "Go!"
8. Click "Allow". (Need microphone connected.)
9. Click select button for "Microphone:"

Expect: dropdown.
Actual: content frozen.

10. Load testcase in a new tab.

Actual: browser frozen.

Set release status flags based on info from the regressing bug 1792785

:kinetik, since you are the author of the regressor, bug 1792785, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Haven't had any luck reproing this so far with my usual Linux setup (Fedora 36/pipewire-pulseaudio 0.3.58) using HDMI audio source and a USB headset as the removable device - at step 6, I get a(nother) permissions dialog for the default (HDMI) device again and the rest of the steps work. Will try again with a few other configurations including a Bluetooth speaker - keeping NI for now.

Karl, do you know if your system is using PulseAudio as the audio server or is it using PipeWire with the PA compatibility layer?

Thank you for attempting to reproduce, Matthew.
The audio server here is PulseAudio. PipeWire is built without the sound server.

The hang didn't reproduce as reliably under rr. For this trace, steps 7 and 8 were moved to before step 3, and step 9 replaced with another click on "Default system output...".
https://pernos.co/debug/oAgAFdZ2Sneqrpj00XnTuQ/index.html#f{m[DmIf,AA_,t[AQ,A1mn_,f{e[A5Zm,eJeQ_,s{af6TiPqAA,bAX0,uBGL/SQ,oBGMA7A___,v[{wiLg,v[{f'list',q'stdouterr',p{_,xAYag_,{f'container',q'stack',p{_,xAYag_,{f'list',q'alerts',p{_,xAYag_,{f'notebook',q'notebook',p.,xAYag___,{w/eg,v[{f'source',q'source',p{_,xAYag____/

On termination during the hang, the parent process main thread is in audioipc2::ipccore::EventLoopHandle::add_connection(). The content process (-childID 2) main and IPC I/O Child threads do not appear to be blocked, so this may not be exactly the same hang. There is a CubebOperation thread in audioipc2_client::stream::ClientStream::init().

Thanks for the Pernosco trace! Working through it now, will update when I have some useful info.

The root cause of this hang appears to be related to handling stream initialization failures with cubeb backends that synchronously trigger error state callbacks during init. AudioIPC's state callback handler sends the state update, but since the client side of the AudioIPC stream is not fully connected yet the client is not listening on the RPC connection and the RPC blocks indefinitely. This results in the stream initialization blocking indefinitely and preventing any further progress on the AudioIPC server thread.

Picks up a single fix to address a deadlock triggered when attempting to
configure an audio device that has been removed.

https://hg.mozilla.org/mozilla-central/rev/7b95363eea8f

Copying crash signatures from duplicate bugs.

I have achieved reproduction with the exact steps from comment 0 in Nightly v109.0a1 from 2022-11-17. Firstly, the content crashed, then, when reopening the test case in a new tab, the whole browser froze, then showed the error "Firefox nightly is not responding".

I can confirm that this issue no longer reproduces in Nightly v112.0a1, Beta v111.0b8 and v111.0 (RC). No freeze was observed in several tries. The testing was performed in Ubuntu 22.