fix(tray): populate Linux right-click menu via setContextMenu - #2856
Conversation
On Linux, trays go through libappindicator / StatusNotifierItem (D-Bus). Electron only emits 'right-click' on that path when no context menu is set, so the popUpContextMenu call inside our JS handler showed an empty menu (or nothing) depending on the desktop environment. Hand the menu to the host indicator instead so it renders natively on right-click. Keep the existing right-click + popUpContextMenu path on macOS / Windows — setContextMenu intercepts left-click on macOS and would break the menubar window toggle. Refs gitify-app#1612, gitify-app#2096. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Some Linux tray providers (e.g. KStatusNotifier-backed indicators on GNOME) require a double-click on the icon to trigger the primary action. A "Toggle Gitify" menu item gives users a guaranteed single-click path to show or hide the popup regardless of the provider's activation behavior. Static label keeps the menu cheap on Linux — no need to rebuild and re-call setContextMenu on visibility changes for a Show/Hide label flip to propagate over D-Bus. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
Can you help me better understand the |
|
It's just Show/Hide for the Gitify window. Applications usually have this in tray menu, I thought Gitify may have this as well. |
Gotcha Is this a common context menu in each Linux app? What would the experience be like if this was left out? |
Out of 14 applications with a tray menu currently installed on my system, only Gitify lacks a "Show window" option. I was so used to this pattern that it never occurred to me it might vary, but as it turns out, there's no real standardization. From this small sample, the most common labels for the entry are:
I went with "Toggle Gitify" as the best compromise between functionality and brevity. From a UX standpoint, though, the ideal solution would be a dynamic entry that reads "Show Gitify" when the window is hidden and "Hide Gitify" when it's visible, giving the user clear, context-aware feedback at a glance. It's also worth noting that this entry carries real accessibility value: for users who rely on keyboard navigation or assistive technologies, the tray menu may be the only reliable way to interact with the application, making a clearly labeled show/hide entry not just convenient but essential. The dynamic label also has a subtle debugging benefit. If the entry reads "Hide Gitify" but the window is nowhere to be seen, that's an immediate signal that something has gone wrong, such as the window being off-screen or on a different workspace. |
|
Super thorough analysis @BlueManCZ, thank you!!!
Let's go forward with this variant then |
Replaces the static "Toggle Gitify" entry with two MenuItems whose visibility tracks the popup window state — the menu now shows "Show Gitify" when the popup is hidden and "Hide Gitify" when it's visible. The window's show/hide events are forwarded to MenuBuilder. On Linux the indicator caches the menu over D-Bus, so after flipping visibility we re-publish via setContextMenu to push the change through immediately rather than wait for the next mutation event. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
3 participants
Summary
Right-clicking the tray icon on Linux opened an empty menu (or nothing at all on some DEs) because the existing
right-click→popUpContextMenuhandler doesn't reach libappindicator / StatusNotifierItem (D-Bus). On that path, Electron only emits theright-clickevent when no context menu is set —setContextMenuinstead hands the menu to the host indicator so it renders natively on right-click.Left-click behavior is unchanged on every platform — menubar's own click handler still toggles the popup. Note that some tray providers (e.g. KStatusNotifier-backed indicators on GNOME) require a double-click to trigger the icon's primary action by design; that's a property of the provider, not something this PR alters either way.
The macOS / Windows code path is intentionally untouched:
setContextMenuintercepts left-click on macOS and would break the menubar window toggle, so those platforms keep the existingright-click+popUpContextMenuhandler.This mirrors the approach we took in zoidsh/meru#498.
Show / Hide menu entries
Adds two entries at the top of the right-click menu —
Show GitifyandHide Gitify— whose visibility tracks the popup state via windowshow/hideevents. Only one is ever visible at a time, giving users a guaranteed single-click path to the popup even on tray providers where icon activation needs a double-click.On Linux, after flipping the items we re-publish the menu via
setContextMenuso the change propagates through D-Bus immediately rather than waiting for the next mutation event. macOS / Windows rely onpopUpContextMenureading the latest menu state at right-click time, so no re-publish is needed there.Test plan
popUpContextMenu; left-click still toggles popup; Show / Hide labels track visibility.pnpm testpasses.May close #1612, #2096 — both threads include the empty/unresponsive right-click menu reported here.
🤖 Generated with Claude Code