Edit:
I turned off my wifi card, and now it launches immediately. Of course, what is a browser with no internet. But I guess there’s something about the network I moved to thats causing the delay. I’ll try a different network tomorrow and update for science
OG post: This applies to librewolf and firefox flatpaks. Just to preface, I’ve been using these flatpaks for years and never experienced anything like this.
This morning I did my business as normal with no issues. I usually open and close firefox alot and it takes maybe 10-30 seconds to start.
Then I shutdown for awhile. Came back and fired up firefox… nothing happened. The process is not using any cpu, it just sits. I kill the process and try again nothing changes. After 3-5 minutes, the window finally pops up.
My system installation of firefox works fine. So does the flatpaks for qutebrowser and tor browser. I ran flatpak repair and reinstalled them. Nothing has changed.
I didn’t make any changes to my system. There were no significant updates. I have no idea why this started.
If anybody has any tips on troubleshooting this, I would appreciate it.
Btw I’m on fedora39, and I’ve tested this on sway, gnome, hyprland, and gnome on xorg.
It usually does that for me when the XDG Desktop Portal borks. Run it from a terminal (flatpak run) and see if it complains about not being able to find a “settings” portal. You can also try to restart the xdg-desktop-portal.service user unit.
No joke, XDP has been so fucky on Hyprland, I have a keybinding to restart it.
I tried restarting portal, didn’t work. systemctl status for xdp did show an error for hyprland about a config file. But I’m running on sway mainly. I just tried out different DE’s to see if anything changed.
Here’s flatpak output
flatpak run --verbose io.gitlab.librewolf-community
F: No installations directory in /etc/flatpak/installations.d. Skipping
F: Opening system flatpak installation at path /var/lib/flatpak
F: Opening user flatpak installation at path /home/auser/.local/share/flatpak
F: Opening user flatpak installation at path /home/auser/.local/share/flatpak
F: Opening user flatpak installation at path /home/auser/.local/share/flatpak
F: /home/auser/.local/share/flatpak/runtime/org.freedesktop.Platform/x86_64/23.08/329ad0f04e21dc3234accff013641299e13a9eb2f1b2908129692b4755393789/files/lib32 does not exist
F: Cleaning up unused container id 75319174
F: Cleaning up per-app-ID state for io.gitlab.librewolf-community
F: Allocated instance id 821024549
F: Add defaults in dir /io/gitlab/librewolf-community/
F: Add locks in dir /io/gitlab/librewolf-community/
F: Allowing dri access
F: Allowing wayland access
F: Allowing pulseaudio access
F: Pulseaudio user configuration file '/home/auser/.config/pulse/client.conf': Error opening file /home/auser/.config/pulse/client.conf: No such file or directory
F: CUPS configuration file '/home/auser/.cups/client.conf': Error opening file /home/auser/.cups/client.conf: No such file or directory
F: Running '/usr/bin/bwrap --args 43 /usr/bin/xdg-dbus-proxy --args=45'
F: Running '/usr/bin/bwrap --args 43 librewolf'
That’s more or less what mine says. What about journalctl, does it print anything in red?
Nope it’s all green.
Idk if you saw my update but turning of the wifi fixes this problem.
I did move to a new network yesterday, I just didn’t think that could impact the flatpak launch, while not affecting the systems binary launch.
It’s a real head scratcher
Sometimes some programs and some downloads have weird slowdowns like this when my VPN is on, even though others remain completely unaffected
What version of xdg-desktop-portal-* package do you have installed? If it’s -gnome try replacing it with -gtk, see if that helps.
The gnome portal is not running. The gtk and wlr portals are, as they have been for months with no issue.
xdg-desktop-portal-wlr.x86_64 0.7.1-1.fc39
xdg-desktop-portal-gtk.x86_64 1.15.1-1.fc39
But is the gnome portal installed? Firefox may still try to use it if it’s there.
You don’t lose anything by uninstalling the gnome portal, the gtk portal takes over.
Could you leave journalctl -f running while Firefox is starting? Anything interesting happening right after initiating the start and/or before it actually starts?
The only thing that came up was some memory allocation/cgroup/.slice stuff for the container.
I’m not on that network anymore, and the problem is gone. So I cant reproduce.
Maybe I should have run wireshark?
Also a dbus notification daemon (whichever you use) may be having problems. Things hang inexplicably if it’s not running.
