COSMIC: cua-driver advertises ScreenReaderEnabled and launches Orca

[maelguimet]

Bug description

On Pop!_OS COSMIC, starting cua-driver serve sets org.a11y.Status.ScreenReaderEnabled=true. COSMIC treats that property as an explicit request to start the screen reader and launches /usr/bin/orca, which in turn socket-activates Speech Dispatcher.

This is the same class of bug fixed for GNOME in #2010 / 8114e17, but the current desktop guard recognizes only GNOME. Since XDG_CURRENT_DESKTOP=COSMIC, COSMIC falls through to AdvertiseMode::All and still advertises a screen reader.

Environment

• OS: Pop!_OS 24.04 LTS
• Desktop: COSMIC
• Session: Wayland with XWayland (XDG_SESSION_TYPE=wayland, DISPLAY=:1)
• XDG_CURRENT_DESKTOP=COSMIC
• cua-driver: 0.12.6 (x86_64-unknown-linux-gnu)
• Hermes Agent using cua-driver over MCP

Steps to reproduce

1. Ensure the screen-reader flags are off:

   gsettings get org.gnome.desktop.a11y.applications screen-reader-enabled
   
   gdbus call --session \
     --dest org.a11y.Bus \
     --object-path /org/a11y/bus \
     --method org.freedesktop.DBus.Properties.Get \
     org.a11y.Status ScreenReaderEnabled

   Both reported false in this session.

2. Start the daemon normally:

   cua-driver serve

3. Observe COSMIC launch Orca and Speech Dispatcher immediately.

Actual behavior

The journal shows the daemon and Orca starting in the same second:

14:29:56  cua-driver serve started
14:29:57  cosmic-session[2520]: starting process ' WAYLAND_DISPLAY=wayland-1 DISPLAY=:1 XDG_SESSION_TYPE=wayland GTK_MODULES=gail:atk-bridge QT_ACCESSIBILITY=1 ... /usr/bin/orca '
14:29:57  systemd[2474]: Started speech-dispatcher.service - Common interface to speech synthesizers.
14:29:57  speech-dispatcher[116448]: Speech Dispatcher 0.12.0-rc2 starting

There was no hotkey, press_key, or other input action preceding the launch; merely starting cua-driver serve reproduced it.

Expected behavior

Starting cua-driver should enable generic AT-SPI inspection without claiming that a screen reader is active or launching Orca.

Root cause

The current desktop default in platform-linux/src/a11y.rs special-cases only GNOME:

let is_gnome = desktop.is_some_and(|desktop| {
    desktop
        .split([':', ';'])
        .any(|part| part.trim().eq_ignore_ascii_case("gnome"))
});
if is_gnome {
    AdvertiseMode::IsEnabledOnly
} else {
    AdvertiseMode::All
}

For XDG_CURRENT_DESKTOP=COSMIC, this selects AdvertiseMode::All, which writes ScreenReaderEnabled=true.

COSMIC explicitly monitors that property and starts Orca when it becomes true: cosmic-session/src/a11y.rs.

Verified workaround

Starting the daemon with:

CUA_DRIVER_RS_A11Y_ADVERTISE_MODE=is_enabled_only cua-driver serve

produces the desired state:

IsEnabled=(<true>,)
ScreenReaderEnabled=(<false>,)

With that mode:

• Orca does not start.
• Speech Dispatcher does not start.
• hermes computer-use doctor still reports both AT-SPI inspection and screen capture as functional.
• A live Computer Use MCP call completes without a new Orca launch event.

Suggested fix

Treat COSMIC like GNOME for the default advertisement mode, and add a regression test:

#[test]
fn cosmic_default_does_not_claim_a_screen_reader() {
    assert_eq!(
        advertise_mode_from(false, None, Some("COSMIC")),
        AdvertiseMode::IsEnabledOnly
    );
}

A broader safety improvement may be to default unknown desktops to IsEnabledOnly, requiring an explicit CUA_DRIVER_RS_A11Y_ADVERTISE_MODE=all where ScreenReaderEnabled is genuinely necessary. The minimal fix is adding COSMIC to the existing non-screen-reader guard.