Bug#1012563: wireplumber: right click broken in firefox 100.0.2-1
Le 05/10/2022 à 08:56, Gabriel Corona a écrit : I collected some stack traces and apparently the problem happens in libcanberra-pulse : If anyone else is affected by this bug, I guess uninstalling the libcanberra-pulse package should fix the problem. Gabriel
Bug#1012563: wireplumber: right click broken in firefox 100.0.2-1
Hi Dylan, I reported this issue to pipewire: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2745 Regards, Gabriel
Bug#1012563: wireplumber: right click broken in firefox 100.0.2-1
Control: tags -1 - unreproducible + confirmed Hi Gabriel, Le mer. 5 oct. 2022 à 09:00, Gabriel Corona a écrit : > > I collected some stack traces and apparently the problem happens in > libcanberra-pulse : > ... > 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. > 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
Bug#1012563: wireplumber: right click broken in firefox 100.0.2-1
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 0x7f5fdee844bb 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 0x7f5fdee86c00 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 0x7f5facf68577 in pa_cond_wait (c=, m=out>) at ../src/pulsecore/mutex-posix.c:146 #6 0x7f5fad53da48 in pa_threaded_mainloop_wait (m=0x7f5f98c52f40) at ../src/pulse/thread-mainloop.c:216 #7 0x7f5fae589d90 in pulse_driver_open (c=0x7f5fa5487440) at ./src/pulse.c:436 #8 0x7f5f94f4e379 in driver_open (c=c@entry=0x7f5fa5487440) at ./src/dso.c:273 #9 0x7f5f94f45868 in context_open_unlocked (c=c@entry=0x7f5fa5487440) at ./src/common.c:293 #10 0x7f5f94f4650e 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 0x7f5f94f46915 in ca_context_play (c=0x7f5fa5487440, id=0) at ./src/common.c:462 #12 0x7f5fd520603c in nsSound::PlayEventSound(unsigned int) () from /home/gabriel/software/firefox/libxul.so #13 0x7f5fd53f19cc in nsMenuPopupFrame::ShowPopup(bool) () from /home/gabriel/software/firefox/libxul.so #14 0x7f5fd53fd8fb in nsXULPopupManager::ShowPopupCallback(nsIContent*, nsMenuPopupFrame*, bool, bool) () from /home/gabriel/software/firefox/libxul.so #15 0x7f5fd53fc7a1 in nsXULPopupManager::BeginShowingPopup(PendingPopup const&, bool, bool) () from /home/gabriel/software/firefox/libxul.so #16 0x7f5fd53fc485 in nsXULPopupManager::ShowMenu(nsIContent*, bool) () from /home/gabriel/software/firefox/libxul.so #17 0x7f5fd53f9d60 in mozilla::detail::RunnableFunction::Run() () from /home/gabriel/software/firefox/libxul.so #18 0x7f5fd7243f80 in mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock const&) () from /home/gabriel/software/firefox/libxul.so #19 0x7f5fd724b2ea in nsThread::ProcessNextEvent(bool, bool*) () from /home/gabriel/software/firefox/libxul.so #20 0x7f5fd72928f5 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) () from /home/gabriel/software/firefox/libxul.so #21 0x7f5fd7dd032f in MessageLoop::Run() () from /home/gabriel/software/firefox/libxul.so #22 0x7f5fd84f4249 in nsBaseAppShell::Run() () from /home/gabriel/software/firefox/libxul.so #23 0x7f5fd5fc75c5 in nsAppStartup::Run() () from /home/gabriel/software/firefox/libxul.so #24 0x7f5fd603cf60 in XREMain::XRE_mainRun() () from /home/gabriel/software/firefox/libxul.so #25 0x7f5fd603d893 in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) () from /home/gabriel/software/firefox/libxul.so #26 0x7f5fd603dc76 in XRE_main(int, char**, mozilla::BootstrapConfig const&) () from /home/gabriel/software/firefox/libxul.so #27 0x55b10856e652 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
Bug#1012563: wireplumber: right click broken in firefox 100.0.2-1
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
Bug#1012563: wireplumber: right click broken in firefox 100.0.2-1
I am glad it is solved on your side. After having discussed with upstream about this issue, there was no obvious culprit. 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
Bug#1012563: wireplumber: right click broken in firefox 100.0.2-1
Hello Raphaël, Le lun. 19 sept. 2022 à 14:13, Raphael Hertzog a écrit : > > It seems to work now with firefox 104.0-1 and wireplumber 0.4.11-4. > 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
Bug#1012563: wireplumber: right click broken in firefox 100.0.2-1
Hello Dylan, On Tue, 13 Sep 2022, Dylan Aïssi wrote: > Do you have a special audio configuration? No. > > 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... > > 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. It seems to work now with firefox 104.0-1 and wireplumber 0.4.11-4. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Bug#1012563: wireplumber: right click broken in firefox 100.0.2-1
Hi Raphaël, I tried to reproduce this issue, but I did not succeed. Le jeu. 9 juin 2022 à 14:51, Raphaël Hertzog a écrit : > > 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. 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? > 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... > 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
Bug#1012563: wireplumber: right click broken in firefox 100.0.2-1
Package: wireplumber Version: 0.4.10-2 Severity: important X-Debbugs-Cc: hert...@debian.org, gland...@debian.org, team+pkg-mozi...@tracker.debian.org Control: affects -1 firefox 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! -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-3-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wireplumber depends on: ii init-system-helpers 1.63 ii libc6 2.33-7 ii libglib2.0-0 2.72.2-2 ii libpipewire-0.3-0 0.3.51-1+b1 pn libwireplumber-0.4-0 ii pipewire 0.3.51-1+b1 Versions of packages wireplumber recommends: ii pipewire-pulse 0.3.51-1+b1 Versions of packages wireplumber suggests: pn libspa-0.2-bluetooth
