https://bugs.kde.org/show_bug.cgi?id=502759
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from [email protected] --- With the help of Claude Opus 4.6 I managed this workaround on my system. I hope someone might find it useful: ## Workaround: Plasma Browser Integration working with Brave (Flatpak) on Fedora + KDE Plasma 6 ### Environment - **OS:** Fedora 43 (Workstation) - **Desktop:** KDE Plasma 6 (Wayland) - **Browser:** Brave 145.1.87.188 (Flatpak: com.brave.Browser) - **Package:** plasma-browser-integration 6.3.4 - **Extension:** Plasma Integration (cimiefiiaegbelhefglklhhakcgmhkai) ### Problem Summary There are **two separate issues** preventing Plasma Browser Integration from working with Flatpak-based Chromium browsers (tested with Brave): #### Issue 1: `"args"` field in native messaging JSON causes bwrap error When the JSON manifest uses `flatpak-spawn` as `"path"` with `"args"` to pass the host binary, the Brave Flatpak sandbox produces: bwrap: execvp chrome-extension://cimiefiiaegbelhefglklhhakcgmhkai/: No such file or directory The browser appears to mishandle the `"args"` array and attempts to execute the `allowed_origins` URI as a command. The solution is to use a wrapper script as the `"path"` directly, with no `"args"` field. #### Issue 2: plasma-browser-integration-host hangs on XDG Desktop Portal When the host binary is launched via `flatpak-spawn --host`, it attempts to connect to the XDG Desktop Portal and hangs indefinitely. Confirmed via `strace`: - **Without workaround:** the process blocks on a D-Bus call to `org.freedesktop.portal.Desktop` and never reaches its main event loop. - **With `QT_NO_XDG_DESKTOP_PORTAL=1`:** the host starts correctly and enters its normal `ppoll()` loop waiting on fd 0 (stdin) for native messaging communication. The strace output clearly shows: ppoll([{fd=0, events=POLLIN}, {fd=5, events=POLLIN}], 2, NULL, NULL, 8 This is the expected behavior — the host is healthy and waiting for the browser to send messages. ### Solution (3 files) #### File 1: Host-side wrapper **Path:** `/usr/local/bin/plasma-browser-integration-host-wrapper` ```bash #!/bin/bash export QT_NO_XDG_DESKTOP_PORTAL=1 exec /usr/bin/plasma-browser-integration-host "$@" sudo chmod +x /usr/local/bin/plasma-browser-integration-host-wrapper #### File 2: Sandbox-side wrapper Path: ~/.var/app/com.brave.Browser/data/plasma-browser-integration-wrapper.sh #!/bin/bash exec flatpak-spawn --host /usr/local/bin/plasma-browser-integration-host-wrapper "$@" chmod +x ~/.var/app/com.brave.Browser/data/plasma-browser-integration-wrapper.sh #### File 3: Native messaging JSON manifest Path: ~/.var/app/com.brave.Browser/config/BraveSoftware/Brave-Browser/NativeMessagingHosts/org.kde.plasma.browser_integration.json { "name": "org.kde.plasma.browser_integration", "description": "KDE Plasma Integration", "path": "<HOME_DIR>/.var/app/com.brave.Browser/data/plasma-browser-integration-wrapper.sh", "type": "stdio", "allowed_origins": [ "chrome-extension://cimiefiiaegbelhefglklhhakcgmhkai/" ] } Note: Replace <HOME_DIR> with your actual home directory path (e.g., /home/username). RESULT After applying the above and restarting Brave: Extension connects successfully (no more "Failed to connect to native host") Media controls work (YouTube videos appear in Plasma media widget) No bwrap: execvp errors in browser output The host process runs cleanly with normal ppoll() event loop KEY FINDINGS The "args" field in native messaging JSON manifests does not work correctly inside the Brave Flatpak sandbox — the path must point directly to an executable script. plasma-browser-integration-host requires QT_NO_XDG_DESKTOP_PORTAL=1 when invoked from a Flatpak context to avoid hanging on portal D-Bus calls. The two-wrapper approach (host-side + sandbox-side) cleanly bridges the Flatpak sandbox boundary. LIMITATIONS This is a workaround, not an upstream fix. The JSON requires a hardcoded home directory path. System updates to plasma-browser-integration should not break this (the wrapper calls the standard binary path), but Brave Flatpak updates could potentially reset the NativeMessagingHosts directory. The upcoming xdg-native-messaging-proxy project should eventually provide a proper solution for native messaging with sandboxed browsers. APPLICABILITY This approach should work for any Chromium-based Flatpak browser (Chrome, Chromium, Edge, Vivaldi) by adapting the paths accordingly. The core technique (two wrappers + QT_NO_XDG_DESKTOP_PORTAL=1 + no "args" in JSON) is universal. -- You are receiving this mail because: You are watching all bug changes.
