Environment
- Repo:
f7e7b5c20865ca9669cfb2aa31037f112d10d976
- ChatGPT Desktop:
26.707.51957
- Electron:
42.1.0
- DMG SHA-256:
a66a0645fd4de6f4f22e75ca87bedb1585aeb57f3457a3df55509bf8da110879
- DMG size:
560735555 bytes
- KDE Plasma on native Wayland
org.freedesktop.portal.GlobalShortcuts version 1org.freedesktop.portal.RemoteDesktop version 2- Only
global-dictation enabled in a side-by-side build
Reproduction
- Build the current DMG with only
global-dictation enabled.
- Launch it on KDE Plasma Wayland with an isolated app id and state directory.
- Configure the hold shortcut as
Ctrl+Shift+F12 through the same global-dictation-set-hotkey IPC used by Settings > Voice.
- Observe the KDE portal window and launcher log for 30 seconds.
Observed behavior
The setter returns success immediately and persists the shortcut:
{
"success": true,
"state": {
"supported": true,
"configuredHotkey": "Ctrl+Shift+F12",
"configuredToggleHotkey": null,
"keepVisible": true
}
}KDE receives the request and creates a Global Shortcuts Requested window, but the window is not associated with or activated over ChatGPT. A KWin window dump showed the portal window as active=false while the side-by-side ChatGPT window remained active.
The KDE portal journal shows why the request has no parent:
xdp-kde-GlobalShortcuts: shortcuts: ... preferred_trigger "CTRL+SHIFT+F12"
xdp-kde-GlobalShortcuts: parent_window: ""
After 30 seconds the helper exits and the feature tears down:
[linux-global-dictation] hold hotkey backend became unavailable Error: Global shortcuts portal registration timed out.
The same result reproduced after restart. The helper is cleaned up correctly, but the persisted shortcut causes the failed registration to be retried.
Cause
The helper currently sends an empty parent identifier to both portal requests:
GlobalShortcuts.BindShortcuts: global-dictation-linux/src/main.rs:480RemoteDesktop.Start: global-dictation-linux/src/main.rs:413
On Wayland the portal parent must be a valid wayland:<xdg_foreign handle>. BrowserWindow.getNativeWindowHandle() is not that handle under Ozone/Wayland, so converting its bytes would not be a valid fix.
The current Electron 42 public API does not expose the exported portal window identifier needed by the separate helper. Chromium already has LinuxUiDelegate::ExportWindowHandle, but using it would require a small native Electron/runtime extension or a different ownership model for the portal session.
Expected behavior
- The approval request is parented to a visible ChatGPT window and can be completed normally.
- The helper reaches
ready after approval and remains alive for activation/deactivation events.
- The same parent identifier is used for the RemoteDesktop keyboard-access prompt used by paste.
- Denial, timeout, restart and quit still clean up the helper and portal sessions.
I did not open a code PR because increasing the timeout, using a KWin script, or fabricating a Wayland handle would only hide the missing contract. Maintainer direction on the acceptable native extension point would be useful before implementation.
Environment
f7e7b5c20865ca9669cfb2aa31037f112d10d97626.707.5195742.1.0a66a0645fd4de6f4f22e75ca87bedb1585aeb57f3457a3df55509bf8da110879560735555bytesorg.freedesktop.portal.GlobalShortcutsversion 1org.freedesktop.portal.RemoteDesktopversion 2global-dictationenabled in a side-by-side buildReproduction
global-dictationenabled.Ctrl+Shift+F12through the sameglobal-dictation-set-hotkeyIPC used by Settings > Voice.Observed behavior
The setter returns success immediately and persists the shortcut:
{ "success": true, "state": { "supported": true, "configuredHotkey": "Ctrl+Shift+F12", "configuredToggleHotkey": null, "keepVisible": true } }KDE receives the request and creates a
Global Shortcuts Requestedwindow, but the window is not associated with or activated over ChatGPT. A KWin window dump showed the portal window asactive=falsewhile the side-by-side ChatGPT window remained active.The KDE portal journal shows why the request has no parent:
After 30 seconds the helper exits and the feature tears down:
The same result reproduced after restart. The helper is cleaned up correctly, but the persisted shortcut causes the failed registration to be retried.
Cause
The helper currently sends an empty parent identifier to both portal requests:
GlobalShortcuts.BindShortcuts:global-dictation-linux/src/main.rs:480RemoteDesktop.Start:global-dictation-linux/src/main.rs:413On Wayland the portal parent must be a valid
wayland:<xdg_foreign handle>.BrowserWindow.getNativeWindowHandle()is not that handle under Ozone/Wayland, so converting its bytes would not be a valid fix.The current Electron 42 public API does not expose the exported portal window identifier needed by the separate helper. Chromium already has
LinuxUiDelegate::ExportWindowHandle, but using it would require a small native Electron/runtime extension or a different ownership model for the portal session.Expected behavior
readyafter approval and remains alive for activation/deactivation events.I did not open a code PR because increasing the timeout, using a KWin script, or fabricating a Wayland handle would only hide the missing contract. Maintainer direction on the acceptable native extension point would be useful before implementation.