Opening links results in "Firefox is already running, but is not responding"

If I run Nightly with the command "./nightly/firefox-bin", and then click a link in an external application, the link opens correctly in the running instance of Firefox.

If I run Nightly with Wayland enabled with the command "env GDK_BACKEND=wayland ./nightly/firefox-bin", then clicking a link in an external application shows me the profile selection window, as if I had just launched Firefox.

I'm running Nightly build 20181120100045.

Fwiw, in my case (clicking on a link in Thunderbird) it even ran the updater (because there was a staged Nightly update in my running session) and only afterwards complained that the browser is already running.

You can run the second firefox command (i.e. your other apps that will launch links in Firefox) with GDK_BACKEND=wayland as well.

But yeah, this should be fixed, Firefox really should try looking for an existing instance via D-Bus first even without explicit GDK_BACKEND. Or at least try D-Bus after not finding anything via X11.

The builds running under Wayland and X11 are separated - it allows you to use X11 firefox for regular work and Wayland version for debug/testing.

Fedora ships firefox-wayland package which provides desktop file and launcher for Firefox on Wayland which can be registered as a default launcher for html links and so on.

I don't think we should enable mixing X11/DBus remote - we had that on Fedora before and it brings a lot of confusions as it depends on which version (X11/Wayland) is recently running.

Anyway, the launchers can be extracted from this rpm file:
https://kojipkgs.fedoraproject.org//packages/firefox/63.0.3/3.fc28/x86_64/firefox-wayland-63.0.3-3.fc28.x86_64.rpm

(In reply to Martin Stránský [:stransky] from comment #3)
> I don't think we should enable mixing X11/DBus remote
I agree.

> launcher for Firefox on Wayland which can be registered as a default launcher for html links
Yes, a custom launcher with GDK_BACKEND=wayland override can be created in ~/.local/share/applications/ and registered using "xdg-settings set default-web-browser custom-launcher.desktop". It would cause the other desktop applications to open the links using the correct version of Firefox.

However, even after creating such a launcher and registering it, Firefox would _not_ detect that it is in fact the default browser and it would offer the user to set it as the default browser. If the user agrees, Firefox would create a new launcher with a name similar to "userapp-Nightly-8YETTZ.desktop" and register it. That launcher, however, would use the Firefox executable _directly_, i.e. without the GDK_BACKEND=wayland override.

That would result in launching the non-Wayland version of Firefox by other desktop applications by default, which would then cause the behavior mentioned in this issue.

I think that one of the ways to resolve this would be to update the process of setting the default browser, so that the created launcher would contain the GDK_BACKEND=wayland override if the Firefox process that creates it also runs on Wayland.

GDK_BACKEND is no longer needed, use MOZ_ENABLE_WAYLAND instead (Bug 1522780).

*** This bug has been marked as a duplicate of bug 1522780 ***

I don't think the change of environment variables has affected the problem here. External apps still use the default launcher, even when existing Firefox is running in Wayland, and setting the default to Wayland via `xdg-settings` still causes Firefox to prompt to reset the default to non-Wayland (as described in comment 5).

(In reply to Michael Cooper [:mythmon] from comment #8)
> I don't think the change of environment variables has affected the problem
> here. External apps still use the default launcher, even when existing
> Firefox is running in Wayland, and setting the default to Wayland via
> `xdg-settings` still causes Firefox to prompt to reset the default to
> non-Wayland (as described in comment 5).

Yes, xdg-settings is not read by Firefox, it's Bug 1526243. Firefox uses Gtk2 routines to set/detect default browser which is incorrect as we're running on Gtk3 now.

This sounds like an issue I'm seeing. I'm using Gnome Shell / Wayland with the Dash to panel extension to get a "taskbar".

When running Nightly with `MOZ_ENABLE_WAYLAND=1`, the shell detects it as a different app, so it shows the Xwayland Nightly as not running, and the Wayland window is missing its icon.

In addition, I can't pin it to the taskbar, and the Xwayland Nightly can't activate the Wayland one. So it's behaving as if `--no-remote` was passed.

The same thing happens when I update Firefox while it's running (but I don't consider that to be an issue).

Note that my Wayland Nightly believes it's the default browser.

I tried changing my .desktop file (the one used for opening links, I think) to `Exec=env MOZ_ENABLE_WAYLAND=1 /opt/firefox-nightly/firefox-bin %u`, but on startup Firefox believes it's not the default browser and creates a new one without the environment variable.

And there seems to be no (easy) way to pin the app. I still think this should block bug 1543600.

Update: after setting `MOZ_ENABLE_WAYLAND=1` globally (e.g. in `~/.pam_environment`), opening links works, so when Wayland gets enabled by default, this issue should no longer occur.

My other problem (the shell not recognizing Firefox as an application) is still blocking IMO, but it's tracked in bug 1530052.

> after setting MOZ_ENABLE_WAYLAND=1 globally (e.g. in ~/.pam_environment), opening links works

Thank you for this tip - it closes one of the more annoying things about using Firefox on Wayland.

> after setting MOZ_ENABLE_WAYLAND=1 globally (e.g. in ~/.pam_environment), opening links works

Thanks after setting this and restarting Firefox it's all working as it should, it also updated the default browser settings and a restart confirms it's been persisted

*** Bug 1589251 has been marked as a duplicate of this bug. ***

You can use MOZ_DBUS_REMOTE to force Firefox to use only DBus as a remote protocol, see:
https://mastransky.wordpress.com/2020/03/16/wayland-x11-how-to-run-firefox-in-mixed-environment/

I recently switched from Nightly to Stable on my Arch Linux + Gnome on Wayland desktop.

I have both `MOZ_DBUS_REMOTE` and `MOZ_ENABLE_WAYLAND` enabled in my `.pam_environment`, both correctly shows up as enabled in `about:support` in the Environment listing, yet this fails to work still and I get a "Firefox is already running..." message whenever I try to launch any link from the OS. Even if I *start* Firefox by clicking a link from another app, if I click the same link again in the same app I get the same result. I'm using the [package](https://www.archlinux.org/packages/extra/x86_64/firefox/) version of latest stable Firefox (`81.0.1`).

The weirdest thing about this is not only did this work on Nightly, but if I launch Nightly now, let it set itself as default browser, this works perfectly well in Nightly - all links from the OS correctly open in the browser. So the issue seems to be in stable, somehow, but I'm running out of ideas how to troubleshoot this so any help would be greatly appreciated.

PS: I have two profiles, a nightly and a stable one, stable is set as a default profile and Stable Firefox correctly launches with that profile set, while Nightly uses the nightly profile.

Not sure if it's quite the same bug, but I've noticed when running with `MOZ_ENABLE_WAYLAND` added to the `/usr/bin/firefox` script in ubuntu that clicking links from other apps works initially after firefox has started, but after some time of a running firefox window being open ends up with a "Firefox is already running, but is not responding. To use Firefox, you must first close the existing Firefox process, restart your device, or use a different profile." message dialog when clicking links from other apps.

Adding `MOZ_DBUS_REMOTE` in addition to `MOZ_ENABLE_WAYLAND` appears to fix this in somewhat limited testing so far.

downstream bug report: https://bugs.launchpad.net/firefox/+bug/1921931

Yes, MOZ_DBUS_REMOTE and MOZ_ENABLE_WAYLAND are the correct variables to run Firefox in mixed environment. That will be fixed automatically when all FF builds uses Wayland, but we need to use that variables until that.

*** Bug 1878528 has been marked as a duplicate of this bug. ***