The last version of firefox-esr to work is 102.15.1 to be able of screensharing on sway.
Does www/firefox work? ports d8a3e1d47a90 seems to have restored WEBRTC_USE_PIPEWIRE.
(In reply to Jan Beich from comment #1) Sadly no, the latest firefox just crash with channel error. And just to be sure that it is not an issue with screen recording, both obs and wf-recorder works. I can screen share with the webcam, but it is not really a good experience. On a side note, in the past I was using hyprland portal (instead of wlr) but I no longer use it with obs (it just crash after selecting the screen, complaining about empty buffer).
So I tested on 118, and it abort due to a stack overflow. Here the backtrace without debug symbols 0x00000008014053d0 in __fail (msg=0x80130f774 "stack overflow detected; terminated") at /usr/src/lib/libc/secure/stack_protector.c:130 #2 0x0000000801405340 in __stack_chk_fail () at /usr/src/lib/libc/secure/stack_protector.c:137 #3 0x00000008083df159 in () at /usr/local/lib/firefox/libxul.so #4 0x000000080624adf4 in mozilla::SyncRunnable::Run() () at /usr/local/lib/firefox/libxul.so #5 0x00000008061bdd13 in mozilla::RunnableTask::Run() () at /usr/local/lib/firefox/libxul.so #6 0x00000008061bb10c in mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) () at /usr/local/lib/firefox/libxul.so #7 0x00000008061ba12a in mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) () at /usr/local/lib/firefox/libxul.so #8 0x00000008061ba3be in mozilla::TaskController::ProcessPendingMTTask(bool) () at /usr/local/lib/firefox/libxul.so #9 0x00000008061c0745 in mozilla::detail::RunnableFunction<mozilla::TaskController::TaskController()::$_4>::Run() () at /usr/local/lib/firefox/libxul.so #10 0x00000008061cdb63 in nsThread::ProcessNextEvent(bool, bool*) () at /usr/local/lib/firefox/libxul.so #11 0x00000008061d1f8e in NS_ProcessNextEvent(nsIThread*, bool) () at /usr/local/lib/firefox/libxul.so #12 0x0000000806735a6e in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) () at /usr/local/lib/firefox/libxul.so #13 0x00000008066ead48 in MessageLoop::Run() () at /usr/local/lib/firefox/libxul.so #14 0x0000000808d642b9 in nsBaseAppShell::Run() () at /usr/local/lib/firefox/libxul.so #15 0x0000000809c2f1e6 in nsAppStartup::Run() () at /usr/local/lib/firefox/libxul.so #16 0x0000000809d033d5 in XREMain::XRE_mainRun() () at /usr/local/lib/firefox/libxul.so #17 0x0000000809d03ab9 in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) () at /usr/local/lib/firefox/libxul.so #18 0x0000000809d03e94 in XRE_main(int, char**, mozilla::BootstrapConfig const&) () at /usr/local/lib/firefox/libxul.so #19 0x0000000001047f8d in main ()
Sorry, I don't work on Firefox in any capacity to avoid burnout (already burned out twice). As a workaround use Chromium for now (see bug 268726 if you need instructions). Regarding xdg-desktop-portal-hyprland file a bug. I can't reproduce inside 13.2/15.0 amd64 jails. Tested on sway-devel and hyprland with obs-studio and ungoogled-chromium.
(In reply to Jan Beich from comment #4) No worries, not burning out is always more important. Indeed using ungoogled-chromium works if I give it the correct dbus address, and I could use the hyprland picker which is great. I may at some point create an issue on the firefox bugzilla to try to fix it upstream, but in the meantime I will most likely use the chromium workaround. For the obs issue with hyprland picker combined with sway (swayFX to be more precise), I don't really use it, it was more a test to see if the portal worked before blaming firefox. Thanks for the link to the mailing list by the way, at least I have a starting point to investigate.
Can you reproduce with firefox >= 122? Works fine here inside 13.2 amd64 jail.
(In reply to Jan Beich from comment #6) Indeed when using firefox v122 I don't have this issue anymore. This is on 14.0