Firefox on Unix is moving away from X11-based remote control

October 1, 2021

On Unix, Firefox has had a long standing feature where you could remote control a running Firefox instance, which is how Firefox insures that running 'firefox <some URL>' works right when you already have Firefox running (probably all browsers implement this on all platforms). For years, there's been two different ways for the Firefoxes to communicate, an older one that used X properties and a more recent one that used D-Bus. Today I discovered that Firefox Nightly has effectively deprecated and removed the X11 based remote control mechanism.

The specific change has the title "Use DBus remote when Firefox is built with --enable-dbus", and is apparently to fix bug 1724242, "Background update applied when mixing X11/Wayland and opening remote link". The broad outline of the problem (which has been an issue for years) is that a Firefox running on Wayland must use D-Bus remote control, but if an X program running in XWayland then tries to start Firefox (for example to open a URL), the new Firefox may (only) try to find a running Firefox via the X mechanism and then fail, with various consequences. The Mozilla solution is to only use D-Bus remote control and basically drop X11 remote control.

(Currently the code is not removed from the Firefox source, but it's not built if D-Bus is enabled in Firefox. Almost all Firefox builds will have D-Bus enabled, both official and from Unix distributions.)

The advantage of D-Bus remote control is that it's simpler and somewhat more reliable, and obviously it works regardless of what is or isn't running under Wayland. The disadvantage of D-Bus remote control is that it doesn't work from other machines you've forwarded X to, unlike the X based remote control. Unfortunately for me, I very much need this to work from at least some remote machines, and so now I do my custom Firefox builds without D-Bus support, which currently doesn't seem to be very limiting.

Sidebar: cross machine remote control of Firefox in a D-Bus world

I can see two ways to make off-machine remote control of Firefox still work if you're stuck with a D-Bus only version of Firefox. The probably harder approach would be to write an X remote control proxy that you ran locally in your X session. This would pretend to be Firefox for the X remote control protocol and then bridge commands and responses to D-Bus. The probably easier approach would be to write a cooperating pair of programs that talked to each other over a SSH connection and proxied the D-Bus protocol. The remote end would claim to be Firefox on your (remote) D-Bus, then pass requests back to the local end over the SSH connection using some simple protocol, where the local end would make D-Bus requests to your local Firefox and pass the answers back.

(There's also a simpler version of the second approach where you don't try to duplicate the D-Bus protocol, but instead just listen on a Unix domain socket and take URLs to pass back to the other end. This requires a new little command on the remote side to connect to your remote relay's Unix domain socket, but that's pretty easy. You could probably build this simpler version with shell scripts.)

Each approach has advantages and drawbacks. Since I already use remote X and have my own remote control program that only speaks the X protocol, I'm biased to the first solution provided that I don't have to actually write the X proxy. In practice, if I have to go to D-Bus I'll probably wind up doing the simpler version of the second approach because I'll be writing it myself.

Written on 01 October 2021.
« Moving averages (and rates) for metrics in Prometheus (and Grafana)
Desktops don't always use NetworkManager's programs »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Oct 1 23:20:13 2021
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.