firefox-remoting-symlink-fix

Patch for a Firefox D-Bus remoting bug on Linux: when the profile path contains a symlink, a plain firefox <url> invocation never finds the already-running instance and instead runs into the locked profile ("Firefox is already running…"), because the client and the server disagree on the D-Bus name they derive from the profile path.

• Filed upstream as Bug 2067776.
• bugreport.md — the report as filed (Toolkit :: Startup and Profile System) with the dbus-monitor evidence and the root-cause walkthrough.
• remoting-canonical-profile-path.patch — fix against Firefox 154.0.1 (applies to toolkit/xre/nsAppRunner.cpp).

The bug in one paragraph

Both remoting sides build the bus name as org.mozilla.<program>.<base64(profile-path)>. A --profile <path> launch goes through XRE_GetFileFromPath(), which calls realpath() — the server registers the canonical path. Profile selection via profiles.ini never canonicalizes — the client asks for the literal path, falls back to the legacy profile-name form, finds neither, and cold-starts against the locked profile. Any symlink in the profile path (e.g. a config tree offloaded to another filesystem) makes the two forms differ permanently.

Observed and traced on Arch Linux, Firefox 154.0.1, with ~/.config/mozilla → /data/...; mechanism confirmed against mozilla-central source. See bugreport.md for the verbatim dbus-monitor trace.

The fix

Canonicalize the profile identity once where it is computed (nsAppRunner.cpp, MOZ_HAS_REMOTE block). Client fallback chain becomes: canonical path → literal path (compat with unpatched servers) → profile name (compat with ancient servers).

Trying it without touching the system Firefox

The patched build lives entirely in its object directory; nothing is installed, /usr/bin/firefox stays stock.

tar xf firefox-154.0.1.source.tar.xz
cd firefox-154.0.1
patch -p1 < ../remoting-canonical-profile-path.patch
./mach bootstrap --application-choice browser --no-system-changes
./mach build
# run the patched client against your running stock instance; -P <name> is
# needed because a build in a new location is a separate "install" and would
# otherwise select its own dedicated profile instead of the running one:
<objdir>/dist/bin/firefox -P default-release some-file.pdf

Verified

Firefox 154.0.1, Arch Linux, profile behind ~/.config/mozilla → /data/..., stock instance running with --profile <literal path>:

• stock client, -P default-release some-file.pdf: no handoff, hangs against the locked profile (killed at 10 s);
• patched client, same arguments: D-Bus handoff in 73 ms, file opens as a tab in the running instance, no second process.