Closed Bug 1508803 Opened 6 years ago Closed 4 years ago

[Wayland] Links in external applications don't open in the existing browser

Categories

(Core :: Widget: Gtk, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox65 --- affected

People

(Reporter: mythmon, Unassigned)

References

(Blocks 1 open bug)

Details

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.
Blocks: wayland
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.
(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).

Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE

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).

Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

(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

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 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.

Status: REOPENED → RESOLVED
Closed: 6 years ago4 years ago
Resolution: --- → WORKSFORME
Resolution: WORKSFORME → WONTFIX
Duplicate of this bug: 1878528
No longer duplicate of this bug: 1878528
See Also: → 1878528
You need to log in before you can comment on or make changes to this bug.