coder / coder/portabledesktop

Plank dock click-to-launch silently no-ops when `dbus-launch` is not on host PATH

Open
#26 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
30
Forks
8
PR merge metrics
No merged PRs in 30d

Description

## Summary

The Plank dock that ships with the default portabledesktop session draws launcher icons, but clicking them is a silent no-op on any host where `dbus-launch` is not on `PATH`. The dock therefore appears functional but is purely cosmetic on those hosts.

A "portable" desktop binary that requires the host to supply `dbus-launch` for a core UI feature is, in practice, not portable — every consuming image hits this until they happen to install a package that pulls in `dbus-x11` transitively.

## Reproduction

Observed on a fresh Coder Agents workspace using `codercom/oss-dogfood:latest` (which does not ship `dbus-x11`), running the default desktop served by `portabledesktop up`.

1. `which dbus-launch` → not found.
2. Open the noVNC viewer; the Plank dock renders with Chrome (and other discovered apps) and tooltips work on hover.
3. Click the Chrome dock icon.
4. Expected: Chrome launches.
5. Actual: nothing happens. `dock.log` shows no spawn lines for the launch. No error surfaces in the UI.

After `sudo apt-get install -y dbus-x11` and restarting Plank (no other changes), clicks immediately begin spawning the target binaries — `dock.log` shows the new child PIDs and Plank's GIO launch path completes. (Post-launch crashes seen with Chrome and Meld in this environment are separate, unrelated issues — Chrome crashpad/ptrace and Meld AT-SPI — and reproduce when launching the same binaries directly outside Plank.)

## Root cause

Plank-reloaded launches desktop entries via GLib/GIO (`GAppInfo.launch_default_for_uri()` and friends), which dispatches over the session D-Bus. When `DBUS_SESSION_BUS_ADDRESS` is unset, GIO's documented fallback is to autolaunch a session bus by exec'ing `dbus-launch` from `PATH`.

The portabledesktop runtime:

- Builds Plank with `-Denable-dbusmenu=no` and strips `dbus-1.0` from the Nix runtime tree (`flake.nix`).
- `BuildEnv` in `pd/internal/desktop/env.go` does not set `DBUS_SESSION_BUS_ADDRESS` or otherwise provision a session bus.
- `StartDock` in `pd/internal/desktop/dock.go` launches Plank with the env from `BuildEnv` only.

So Plank inherits a `PATH` that, on a stock image without `dbus-x11`, has no `dbus-launch`. GIO's autolaunch silently fails and the launch RPC never reaches a handler. The icon-drawing path doesn't need the bus, which is why this presents as "icon visible, click does nothing."

## Suggested fixes (in order of preference)

1. **Wrap Plank in `dbus-run-session`** inside `StartDock` so each session gets its own bus deterministically, regardless of host.
2. **Bundle `dbus-launch` / `dbus-daemon` in the embedded Nix runtime** so the binary stays self-contained per its README ("no containers or display servers to configure").
3. At minimum, **detect the missing bus at dock startup** and log a clear error to `dock.log` (and ideally surface it in the dock startup error path) instead of silently producing a cosmetic dock.

Happy to send a PR for option 1 if that's the preferred direction.

## Impact

- Affects every host image that doesn't already pull in `dbus-x11` (or equivalent).
- Currently silent: there is no error in `dock.log`, viewer, or CLI output, so it presents to users as "the dock is broken" rather than "a dependency is missing."
- Workaround for image maintainers: install `dbus-x11`. This was verified end-to-end on the dogfood image.

---

_Filed on behalf of @tracyjohnsonux by a Coder Agents-generated agent._

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.