Description

Since upgrading to 4.14.0, the Electron-native desktopCapturer picker dialog ("Rocket.Chat wants to share your screen. Choose what you'd like to share.") opens automatically at every application startup, before any user action related to screen sharing. Cancelling it closes the dialog, but it reappears on the next launch.

The same Rocket.Chat server used via the web client (Firefox/Chrome) does not trigger this dialog — the bug is specific to the desktop app.

Environment

• Desktop app: Rocket.Chat 4.14.0 (Flatpak from Flathub, chat.rocket.RocketChat)
• OS: Fedora 43, Linux kernel 6.19.12
• Display server: Wayland
• Electron runtime args observed: --ozone-platform=wayland, --enable-features=WebRTCPipeWireCapturer, --autoplay-policy=no-user-gesture-required
• Rocket.Chat server: self-hosted, current stable

Reproduction

1. Install chat.rocket.RocketChat 4.14.0 from Flathub
2. Launch the app, connect to any Rocket.Chat server
3. Close and relaunch the app
4. Expected: app opens normally, no picker dialog
5. Actual: "Share Screen" picker dialog appears on top of the main window immediately

Fully reproducible on a clean install (uninstall + --delete-data + reinstall) → not related to persisted user state.

Suspected root cause

Likely introduced by PR #3266 ("Add screen sharing support for server view"). Before 4.14.0, setDisplayMediaRequestHandler was installed only on the video-call window session. Since 4.14.0, a handler is registered on every server-view webview (setupServerViewDisplayMedia(guestWebContents) on WEBVIEW_READY).

Hypothesis: a module in the Rocket.Chat webapp calls navigator.mediaDevices.getDisplayMedia() at load time (probably a capability probe). Before 4.14.0, no handler → silent rejection. In 4.14.0, the newly-registered handler catches the call → picker opens unconditionally.

This would also explain why the browser version is unaffected (browsers require a user gesture for getDisplayMedia, so the probe rejects silently), while Electron with --autoplay-policy=no-user-gesture-required does not.

Workaround

Downgrading the Flatpak to 4.13.0 (commit 586d17963b2556f31217acb59bdcd846a299f436e8ba5ee48ad2792f0525c470, dated 2026-03-07, last release before PR #3266) removes the bug. Masking updates afterwards prevents auto-upgrade back to 4.14.0.

Suggested fix direction

Either:

• Register the display-media request handler only when an actual call/screen-share is initiated by the user (late binding), or
• Ignore getDisplayMedia calls on the server-view webview that are not preceded by a user gesture / explicit call to a known sharing API.