Hello,

Following the recommendation of
https://tracker.debian.org/news/1329911/accepted-pipewire-media-session-041-3-source-into-unstable/
I installed "wireplumber". But after having switched, Firefox started to
behave strangely: any time that I would "right click" on a link or a
field, or anywhere where you can expect the right click to open a
contextual menu, it would "freeze" for a varying number of seconds and
it would not display the contextual menu once the freeze was over.

I switched back to pipewire-media-session and I created
/usr/share/pipewire/media-session.d/with-pulseaudio to get the sound back
and it works again now.

I'm not sure how both behaviour are related, but they seem to clearly be
related.

When I had the issue, I tried to open "about:support", it also triggered
one of those freezes but in the end I was able to see that firefox was
using "alsa" as audio-backend.

Now that I switched back to "pipewire-media-session" and that firefox is
now behaving correctly, I see that it uses the "pulse-rust" audio backend.

So somehow, wireplumber + pipewire-pulse is not properly
detected as something that can be controlled with the "pulse-rust" audio
backend when it likely should be that way...

I don't know if this needs a fix in firefox or in wireplumber. I'm
assigning it wireplumber for a start but I have cced Mike Hommey (the
firefox maintainer).

Thank you all for your great work on those packages!

Hi Raphaël,

I tried to reproduce this issue, but I did not succeed.

Le jeu. 9 juin 2022 à 14:51, Raphaël Hertzog <hertzog@debian.org> a écrit :

Installing wireplumber is (in theory) enough to make firefox using its
pulse-rust audio backend.
Thus having alsa as audio backend results probably from a conflict,
don't know which one.

Do you have a special audio configuration?

May I ask you to give wireplumber a second chance to check if you can
reproduce this issue?
Just install wireplumber, this will remove pipewire-media-session. No
need to remove the
"with-pulseaudio" file. After a reboot I hope everything will be fine.

Best,
Dylan

Hello Dylan,

No.

It seems to work now with firefox 104.0-1 and wireplumber 0.4.11-4.

Cheers,

Hello Raphaël,

Le lun. 19 sept. 2022 à 14:13, Raphael Hertzog <hertzog@debian.org> a écrit :

I am glad it is solved on your side.
After having discussed with upstream about this issue, there was no
obvious culprit.

I will keep this issue open anyway for a while just in case.

Best,
Dylan

I believe, I am having the same issue.

Sometimes, Firefox and Thunderbird freeze completely when you try to open a menu of an
HTML combobox. The application need to be killed. But even after restarting the
application, it is still not possible to open a menu.

I reproduces the issue with:

* firefox, firefox-esr from Debian testing;
* firefox-esr firefox-esr from Debian testing;
* Firefox, Firefox Nightly and Firefox Developer edition downloaded from Mozilla.
* Thunderbird downloaded from thunderbird.net.

This is not reliably reproducible, it only happens from time to time.
once it starts happening, restarting the application does not fix the problem
and all the affected applications are affected at the same time.

What does not fix the issue:

* restarting the application.

What fixes the issue:

* restarting the system;
* killing wireplumber;
* killing and restarting wireplumber.

Configuration:

* Debian testing;
* wireplumber with the "combined sink" plugin enabled (I will try to see if this happens without this plugin);
* pipewire, wireplumber, pipewire-alsa, pipewire-pulse;
* X11, XFCE.

Gabriel

Hi,

I found that killing pipwire-pulse unfeezes the frozen application.
After that, pipwire-pulse can be restarted.

This is in contrast to killing wireplumber or pipewire: this would not
unfreeze the frozen applications; restarting the frozen application was
needed in these cases.

Maybe some kind of deadlock in dbus communications?

Gabriel

Hi,

I collected some stack traces and apparently the problem happens in
libcanberra-pulse :

Thread 1 (Thread 0x7f5fdf4bb780 (LWP 2004) "firefox-bin"):
#0  __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0,
op=393, expected=0, futex_word=0x7f5f992d5f3c) at ./nptl/futex-internal.c:57
#1  __futex_abstimed_wait_common
(futex_word=futex_word@entry=0x7f5f992d5f3c, expected=expected@entry=0,
clockid=clockid@entry=0, abstime=abstime@entry=0x0,
private=private@entry=0, cancel=cancel@entry=true) at
./nptl/futex-internal.c:87
#2  0x00007f5fdee844bb in __GI___futex_abstimed_wait_cancelable64
(futex_word=futex_word@entry=0x7f5f992d5f3c, expected=expected@entry=0,
clockid=clockid@entry=0, abstime=abstime@entry=0x0,
private=private@entry=0) at ./nptl/futex-internal.c:139
#3  0x00007f5fdee86c00 in __pthread_cond_wait_common (abstime=0x0,
clockid=0, mutex=0x7f5f97b907c0, cond=0x7f5f992d5f10) at
./nptl/pthread_cond_wait.c:503
#4  ___pthread_cond_wait (cond=0x7f5f992d5f10, mutex=0x7f5f97b907c0) at
./nptl/pthread_cond_wait.c:618
#5  0x00007f5facf68577 in pa_cond_wait (c=<optimized out>, m=<optimized
out>) at ../src/pulsecore/mutex-posix.c:146
#6  0x00007f5fad53da48 in pa_threaded_mainloop_wait (m=0x7f5f98c52f40)
at ../src/pulse/thread-mainloop.c:216
#7  0x00007f5fae589d90 in pulse_driver_open (c=0x7f5fa5487440) at
./src/pulse.c:436
#8  0x00007f5f94f4e379 in driver_open (c=c@entry=0x7f5fa5487440) at
./src/dso.c:273
#9  0x00007f5f94f45868 in context_open_unlocked
(c=c@entry=0x7f5fa5487440) at ./src/common.c:293
#10 0x00007f5f94f4650e in ca_context_play_full
(c=c@entry=0x7f5fa5487440, id=id@entry=0, p=0x7f5f991c7de0,
cb=cb@entry=0x0, userdata=userdata@entry=0x0) at ./src/common.c:517
#11 0x00007f5f94f46915 in ca_context_play (c=0x7f5fa5487440, id=0) at
./src/common.c:462
#12 0x00007f5fd520603c in nsSound::PlayEventSound(unsigned int) () from
/home/gabriel/software/firefox/libxul.so
#13 0x00007f5fd53f19cc in nsMenuPopupFrame::ShowPopup(bool) () from
/home/gabriel/software/firefox/libxul.so
#14 0x00007f5fd53fd8fb in
nsXULPopupManager::ShowPopupCallback(nsIContent*, nsMenuPopupFrame*,
bool, bool) () from /home/gabriel/software/firefox/libxul.so
#15 0x00007f5fd53fc7a1 in
nsXULPopupManager::BeginShowingPopup(PendingPopup const&, bool, bool) ()
from /home/gabriel/software/firefox/libxul.so
#16 0x00007f5fd53fc485 in nsXULPopupManager::ShowMenu(nsIContent*, bool)
() from /home/gabriel/software/firefox/libxul.so
#17 0x00007f5fd53f9d60 in
mozilla::detail::RunnableFunction<nsMenuFrame::OpenMenu(bool)::$_0>::Run()
() from /home/gabriel/software/firefox/libxul.so
#18 0x00007f5fd7243f80 in
mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&>
const&) () from /home/gabriel/software/firefox/libxul.so
#19 0x00007f5fd724b2ea in nsThread::ProcessNextEvent(bool, bool*) ()
from /home/gabriel/software/firefox/libxul.so
#20 0x00007f5fd72928f5 in
mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) () from
/home/gabriel/software/firefox/libxul.so
#21 0x00007f5fd7dd032f in MessageLoop::Run() () from
/home/gabriel/software/firefox/libxul.so
#22 0x00007f5fd84f4249 in nsBaseAppShell::Run() () from
/home/gabriel/software/firefox/libxul.so
#23 0x00007f5fd5fc75c5 in nsAppStartup::Run() () from
/home/gabriel/software/firefox/libxul.so
#24 0x00007f5fd603cf60 in XREMain::XRE_mainRun() () from
/home/gabriel/software/firefox/libxul.so
#25 0x00007f5fd603d893 in XREMain::XRE_main(int, char**,
mozilla::BootstrapConfig const&) () from
/home/gabriel/software/firefox/libxul.so
#26 0x00007f5fd603dc76 in XRE_main(int, char**, mozilla::BootstrapConfig
const&) () from /home/gabriel/software/firefox/libxul.so
#27 0x000055b10856e652 in ma in ()
[Inferior 1 (process 2004) detached]

Apparently clicking on a menu triggers a canberra notification which
goes trough pulseaudio. Looking at canberra source code, it creates a
pulse audio threaded mainloop which appears to never reach the
PA_CONTEXT_READY state.

Gabriel

Hi Gabriel,

Le mer. 5 oct. 2022 à 09:00, Gabriel Corona
<gabriel.corona@enst-bretagne.fr> a écrit :

Thanks a lot for your investigation!

Because you are able to reproduce this issue, could you report it and all your
findings to the pipewire bug tracker? Even if it's not a pipewire bug,
we will receive
feedback from pipewire/wireplumber devs.

https://gitlab.freedesktop.org/pipewire/pipewire/-/issues

Best,
Dylan

Hi Dylan,

I reported this issue to pipewire:

https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2745

Regards,

Gabriel

Le 05/10/2022 à 08:56, Gabriel Corona a écrit :

If anyone else is affected by this bug, I guess uninstalling the
libcanberra-pulse package should fix the problem.

Gabriel