flathub/io.gitlab.librewolf-community

[Flathub] Cannot launch second window of LibreWolf, getting error

Closed this issue · 5 comments

RagglenLove commented

I'm running the flathub version of LibreWolf 94.0 on Xubuntu 20.04. I startup LibreWolf and it runs okay, but when I click on the LibreWolf launcher on my panel to get another LibreWolf window running, I'm getting this error:

"LibreWolf is already running, but is not responding. To use LibreWolf, you must first close the existing LibreWolf process, restart your device, or use a different profile."

To see what's happening under the hood, I ran LibreWolf in the Terminal and these are the results:

I was able to run LibreWolf from the Terminal:

~$ flatpak run io.gitlab.librewolf-community
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
JavaScript error: resource://gre/modules/PromiseWorker.jsm, line 106: Error: Could not get children of file(/home/RagglenLove/.var/app/io.gitlab.librewolf-community/cache/librewolf/xxxxxxxx.default-release/thumbnails) because it does not exist
JavaScript error: moz-extension://5793ff7d-2782-4a84-a020-41d927b33efb/lib/main.js, line 306: Error: Could not establish connection. Receiving end does not exist.
JavaScript error: undefined, line 0: Error: Content script already unregistered
JavaScript error: undefined, line 0: Error: Content script already unregistered
JavaScript error: undefined, line 0: Error: Content script already unregistered
JavaScript error: undefined, line 0: Error: Content script already unregistered
JavaScript error: moz-extension://5793ff7d-2782-4a84-a020-41d927b33efb/lib/main.js, line 306: Error: Could not establish connection. Receiving end does not exist.

I opened another Terminal window and tried to launch second window of LibreWolf, this is what happened.

The "LibreWolf is already running, but is not responding" error appears and this is the Terminal result:

~$ flatpak run io.gitlab.librewolf-community
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
RagglenLove commented

UPDATE: I've downgraded back to LibreWolf 93.0 and the issue was fixed, so this is a problem with LibreWolf 94.0.

flatpak remote-info --log flathub io.gitlab.librewolf-community

sudo flatpak update \
  --commit=fbdb6b9d8be4016b8f715f1fb8b395bcb240c508512ea4a2f63c8577f91d2fd9 \
  io.gitlab.librewolf-community
BrunoBernardino commented

Another update, it seems the issue is related to the LibreWolf 94.0 flatpak version, not LibreWolf 94.0 itself, as the AppImage doesn't have this problem. Another report with some more info: https://gitlab.com/librewolf-community/browser/linux/-/issues/256#note_726550959

RagglenLove commented
2021-11-10.12-34-12.mp4

Here's a video of this bug in action.

RagglenLove commented

Temporary solution found: https://gitlab.com/librewolf-community/browser/linux/-/issues/256#note_740596927

I found this is caused by the fact that LibreWolf can't talk to its other instance over D-Bus due to the default (restrictive) sandbox profile.

This can be overridden by adding the following to /var/lib/flatpak/overrides/io.gitlab.librewolf-community:

[Context]
sockets=x11;wayland;pulseaudio;fallback-x11;pcsc;session-bus

(The session-bus part was added at the end, from the default LibreWolf profile).

Thank you so much, that worked. In my case, it's /home/RagglenLove/.local/share/flatpak/overrides/io.gitlab.librewolf-community:

[Context]
sockets=x11;wayland;pulseaudio;fallback-x11;pcsc;session-bus

Because /var/lib/flatpak/overrides/io.gitlab.librewolf-community doesn't exist.

Now I can launch multiple instances of LibreWolf 94.0. Thank you.

I'm still not sure how this regressed recently. Maybe sandbox defaults have changed?

I'd like to know the same thing too.

  • ❤️1
lsfxz commented

This should now be fixed with 2dd62ff, so there is no need to fully expose the d-bus session bus to the sandbox anymore.

MOZ_DBUS_REMOTE is not required anymore as well to get things working as it was dropped.

Internally, the LibreWolf builds currently get a org.mozilla.librewolf session name, which is obviously not optimal and which was part of the issue. I'll address that (and possible side effects of changing that) in a seperate issue though.

  • ❤️1