github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-08-24 19:50:09 -05:00
Code Issues 690 Packages Projects Releases 13 Wiki Activity

[PR #2649] [MERGED] fix(desktop): rebuild tray menu in place instead of recreating the Tray #8431

New Issue
Closed
opened 2026-04-20 18:12:53 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-04-20 18:12:53 -05:00
Owner
Copy Link
Copy Source

📋 Pull Request Information

Original PR: https://github.com/go-vikunja/vikunja/pull/2649
Author: @Tokra110
Created: 4/16/2026
Status: ✅ Merged
Merged: 4/17/2026
Merged by: @kolaente

Base: main ← Head: fix/desktop-tray-menu-update

📝 Commits (1)

  • 2a20aa9 fix(desktop): rebuild tray menu in place instead of recreating the Tray

📊 Changes

1 file changed (+13 additions, -15 deletions)

View changed files

📝 desktop/main.js (+13 -15)

📄 Description

Summary

On KDE Plasma 6 Wayland, tray-menu item clicks stop firing their JS callbacks shortly after the app starts. This fix keeps the Tray object alive across menu updates so the dbusmenu event routing stays intact.

Symptom

On KDE Plasma 6 + Wayland (reproduced on Plasma 6.6.1, also reported generically against Electron on other SNI-driven desktops):

  1. Launch the desktop app. Tray icon appears.
  2. Right-click the tray. Context menu opens, items render correctly.
  3. Click any menu item. Nothing happens. The handler never fires. Show Vikunja doesn't show, Quick Add Task doesn't open, Quit doesn't quit.
  4. tray.on('click') also stops firing.

Triggered every time the frontend auth store finishes loading settings.

Root cause

After the auth store loads settings it calls window.vikunjaDesktop.updateQuickEntryShortcut(...) from frontend/src/stores/auth.ts. That sends a desktop:update-quick-entry-shortcut IPC, and the handler in desktop/main.js calls setupTray() so the menu's accelerator label matches the new shortcut.

The old setupTray() starts with tray.destroy() and then creates a fresh Tray(icon). On Linux with KDE Plasma 6 Wayland:

  • tray.destroy() does not actually remove the icon from plasmashell (see electron/electron#49517, open).
  • The new Tray registers a fresh dbusmenu connection, but plasmashell keeps talking to the old (now orphaned) one.
  • The menu items still render (plasmashell already has the DBusMenu layout cached), but every com.canonical.dbusmenu.Event("clicked", ...) method call from plasmashell hits the destroyed handler and is dropped.

Confirmed via dbus-monitor: plasmashell correctly sends Event(int32 <id>, "clicked", ...) to the app's dbus connection on every menu click, but Electron never invokes the JS callback. A minimal Electron reproduction where tray.setContextMenu(newMenu) is called without destroying the Tray works correctly in the same environment.

Fix

Don't recreate the Tray. Create it once, and only swap the context menu in place when the accelerator changes:

  • Move the one-time initialization (new Tray(icon), setToolTip, on('click')) behind a !tray guard.
  • Always rebuild and set the context menu, since that is the part that actually changes.

The desktop:update-quick-entry-shortcut IPC handler keeps calling setupTray(), and the right thing happens without touching the native Tray object.

Test plan

  • Fedora 43, KDE Plasma 6.6.1, Wayland, Electron 40.9.1. Verified across multiple login cycles that Show Vikunja, Quick Add Task, and Quit all fire from the tray menu.
  • Also verified with Electron 39.8.8 that the bug and the fix behave the same, ruling out a recent Electron regression.
  • dbus-monitor trace confirms Event \"clicked\" method calls from plasmashell now reach the JS callbacks after the frontend triggers a menu rebuild.
  • Minimal reproduction: with tray.destroy(); new Tray(...) the click events drop; with tray.setContextMenu(newMenu) the click events fire.

Related

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/go-vikunja/vikunja/pull/2649 **Author:** [@Tokra110](https://github.com/Tokra110) **Created:** 4/16/2026 **Status:** ✅ Merged **Merged:** 4/17/2026 **Merged by:** [@kolaente](https://github.com/kolaente) **Base:** `main` ← **Head:** `fix/desktop-tray-menu-update` --- ### 📝 Commits (1) - [`2a20aa9`](https://github.com/go-vikunja/vikunja/commit/2a20aa944d5368decdca75d2fa2e838df4fcd3bb) fix(desktop): rebuild tray menu in place instead of recreating the Tray ### 📊 Changes **1 file changed** (+13 additions, -15 deletions) <details> <summary>View changed files</summary> 📝 `desktop/main.js` (+13 -15) </details> ### 📄 Description ## Summary On KDE Plasma 6 Wayland, tray-menu item clicks stop firing their JS callbacks shortly after the app starts. This fix keeps the `Tray` object alive across menu updates so the dbusmenu event routing stays intact. ## Symptom On KDE Plasma 6 + Wayland (reproduced on Plasma 6.6.1, also reported generically against Electron on other SNI-driven desktops): 1. Launch the desktop app. Tray icon appears. 2. Right-click the tray. Context menu opens, items render correctly. 3. Click any menu item. Nothing happens. The handler never fires. Show Vikunja doesn't show, Quick Add Task doesn't open, Quit doesn't quit. 4. `tray.on('click')` also stops firing. Triggered every time the frontend auth store finishes loading settings. ## Root cause After the auth store loads settings it calls `window.vikunjaDesktop.updateQuickEntryShortcut(...)` from `frontend/src/stores/auth.ts`. That sends a `desktop:update-quick-entry-shortcut` IPC, and the handler in `desktop/main.js` calls `setupTray()` so the menu's accelerator label matches the new shortcut. The old `setupTray()` starts with `tray.destroy()` and then creates a fresh `Tray(icon)`. On Linux with KDE Plasma 6 Wayland: - `tray.destroy()` does not actually remove the icon from plasmashell (see [electron/electron#49517](https://github.com/electron/electron/issues/49517), open). - The new `Tray` registers a fresh dbusmenu connection, but plasmashell keeps talking to the old (now orphaned) one. - The menu items still render (plasmashell already has the DBusMenu layout cached), but every `com.canonical.dbusmenu.Event("clicked", ...)` method call from plasmashell hits the destroyed handler and is dropped. Confirmed via `dbus-monitor`: plasmashell correctly sends `Event(int32 <id>, "clicked", ...)` to the app's dbus connection on every menu click, but Electron never invokes the JS callback. A minimal Electron reproduction where `tray.setContextMenu(newMenu)` is called without destroying the Tray works correctly in the same environment. ## Fix Don't recreate the `Tray`. Create it once, and only swap the context menu in place when the accelerator changes: - Move the one-time initialization (`new Tray(icon)`, `setToolTip`, `on('click')`) behind a `!tray` guard. - Always rebuild and set the context menu, since that is the part that actually changes. The `desktop:update-quick-entry-shortcut` IPC handler keeps calling `setupTray()`, and the right thing happens without touching the native `Tray` object. ## Test plan - [x] Fedora 43, KDE Plasma 6.6.1, Wayland, Electron 40.9.1. Verified across multiple login cycles that Show Vikunja, Quick Add Task, and Quit all fire from the tray menu. - [x] Also verified with Electron 39.8.8 that the bug and the fix behave the same, ruling out a recent Electron regression. - [x] `dbus-monitor` trace confirms `Event \"clicked\"` method calls from plasmashell now reach the JS callbacks after the frontend triggers a menu rebuild. - [x] Minimal reproduction: with `tray.destroy(); new Tray(...)` the click events drop; with `tray.setContextMenu(newMenu)` the click events fire. ## Related - [electron/electron#49517](https://github.com/electron/electron/issues/49517): Tray icon can't be destroyed on Linux. Upstream, open. - [electron/electron#28837](https://github.com/electron/electron/issues/28837): Menu instance events not firing when used as tray context menu on Linux. Upstream, closed as stale, same class of bug. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-04-20 18:12:53 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
area/attachments
area/auth
area/avatars
area/backup-restore
area/caldav
area/calendar-view
area/comments
area/config
area/database
area/desktop
area/docker
area/email
area/favorites
area/filters
area/frontend
area/gantt
area/i18n
area/import-export
area/internal-code
area/kanban
area/labels
area/list-view
area/mobile
area/notifications
area/permissions
area/projects
area/pwa
area/recurring-tasks
area/reminders
area/search
area/shortcuts
area/subtasks
area/sync
area/table-view
area/task-editor
area/task-metadata
area/task-relations
area/teams
area/theming
area/time-tracking
area/typesense
area/views
area/webhooks
bug
changes requested
concern/accessibility
concern/performance
concern/regression
concern/ux
confirmed
db/mysql
dependencies
enhancement
good first issue
help wanted
integration/inbound
integration/outbound
kind/bug
kind/feature
needs reproduction
pull-request
Mirrored from GitHub Pull Request
 pull-request
Mirrored from GitHub Pull Request
 pull-request
Mirrored from GitHub Pull Request
 question
security
support
upstream issue
waiting for reply
wontfix
No labels pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
GiteaMirror ninjasurge (Kaehlen Rog)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vikunja#8431