Chris's Wiki :: blog/unix/FirefoxDBusRemoteControl

Firefox now implements its remote control partly over D-Bus

+ +

August 3, 2018

On Unix, Firefox has had a long standing feature where you could +remote control a running Firefox instance. +This has traditionally worked through X properties (with two +generations of protocols), which has +the nice advantage that it works from remote machines as well as +your local one, provided that you're forwarding X. Since I read my +mail through exmh that's running on one +of our servers, not my desktop, this is pretty useful for me; I can +click on a link in mail in exmh, and it opens in my desktop Firefox. +However, working through X properties also has the disadvantage +that it naturally doesn't work at all on Wayland. Since +Wayland is increasingly important, last November or so the Mozilla +people fixed this by adding a new D-Bus based protocol (it landed +in bug 1360560 +and bug 1360566 +but has evolved in various ways since then).

+ +

On current versions of Firefox, you will find this service on the +session bus under the name org.mozilla.firefox.<something>, where +the <something> is often 'ZGVmYXVsdA__'. In general this weird +thing is the base64 encoded name of your Firefox profile with a few +special characters turned into _, and that particular name is, +well:

+ +

+; echo -n default | base64
+ZGVmYXVsdA==
+

+ +

Because this directly encodes the profile name in something that +you have to get right, the D-Bus based version of Firefox remote +control will reliably restrict itself to talking to a running Firefox +that's using the same profile; the X properties based version doesn't +always (or didn't always, at any rate). You can force a new Firefox +to not try to talk to an existing Firefox by using --new-instance, +as before.

+ +

(One case where you might need this is if you're testing an +alternate version of Firefox by manually setting your $HOME +to, eg, /tmp/ffox-test.)

+ +

It turns out that which protocol Firefox uses when is a bit tangled. +If Firefox is built with D-Bus support, a running Firefox on X will +be listening for incoming requests using both D-Bus and the X +properties based protocol; you can talk to this Firefox with either. +In the current Firefox code, if you built with both D-Bus and Wayland +support, the client Firefox always uses D-Bus to try to talk to the +running 'server' Firefox; it doesn't fall back to X properties if +there's no D-Bus available. If you built Firefox without Wayland +support, it always uses the X properties based protocol (even if +you built with D-Bus, and so the running Firefox is listening there). +You can see this sausage being made in StartRemoteClient() here.

+ +

This logic was introduced in the change for bug 1465371. Before then +Firefox tried to use the X properties based remote control if it +was running on X, and fell back to the D-Bus protocol otherwise. +In thinking about it I've come to believe that the logic here is +sound, because in a Wayland session you may have some programs that +think they're running in X and then pass this view on to things run +from them. D-Bus is more session type agnostic, although it only +works on the local machine.

+ +

Note that this implies that you can no longer use Firefox itself +as a client on a second machine, at least not if your second machine +Firefox is a modern one that was built with Wayland support; it'll +try to talk D-Bus and fail because your running Firefox isn't on +that machine. If you want to remote control Firefox from a second +machine, you now want a dedicated client like my ffox-remote +program.

+ +

(Hopefully Mozilla will leave the X properties based protocol there +for many years to come, so my cross-machine remote control will still +keep working.)

+ +

Sidebar: some D-Bus protocol details

+ +

The D-Bus object path is /org/mozilla/firefox/Remote, which has one +org.mozilla.firefox method, OpenURL(), all of which you can see +by using a D-Bus browsing program such as d-feet. In the Firefox source code, +what you want to look at is widget/xremoteclient/DBusRemoteClient.cpp +(the client side, ie the firefox command you just ran that is +going to pass your URL or whatever to the currently running one) +and toolkit/components/remote/nsDBusRemoteService.cpp (the server +side, ie the running Firefox).

+ +

Despite the fact that D-Feet will tell you that the argument to +OpenURL() is a string, in actuality it's an entire command line +encoded in the same annoying binary encoding that is used in the +current X property based protocol, which you can read a concise +description of in nsRemoteService.cpp. +Presumably this minimizes code changes, although it's not the most +natural D-Bus interface. This encoding does mean that you're going +to need some moderately tangled code to remote-control Firefox over +D-Bus; you can't fire up just any old D-Bus client program for it.

+ +

The client code for this is in toolkit/xre/nsAppRunner.cpp, +in the StartRemoteClient() function.

Comments on this page:

By Tüdelbüdel at 2018-08-04 07:04:51:

Ah yes, the remote control feature, because it is SO FUNNY if you want to open /home/tuedel/localinfo.html and the request gets sent to a totally different computer.
+ +
That was literally the only time I was confronted with that feature. It took a while to figure out what was even happening and then how to avoid it. Even with my current knowledge, I would be hard pressed to find the relevant section in the firefox user documentation.
+ +
And this seems to be a general problem with complex software (browsers, *office, gimp etc.): You can start using them without reading any documentation, but when strange complex things happen or when you need more in-depth information on some feature, the answer will more likely be found in a stackoverflow posting or something, not the built in documentation.
+ +
Of course it would be a huge effort to always write and maintain such comprehensive and in-depth documentation, so I am not complaining.
+

+ +

+ Written on 03 August 2018.
+ + + +

«	How I want to use Go's versioned modules

Why email is often not as good as modern communication protocols

+ +