App becomes unresponsive via tray icon after minimizing (Wayland/GNOME)

[faasie]

Environment

• OS: Fedora 43
• Desktop: GNOME Shell 49.2
• Session: Wayland
• notion-electron version: 1.9.3 (RPM)
• AppIndicator extension: v61 (appindicatorsupport@rgcjonas.gmail.com)

Description

After minimizing the app (which hides the window to tray), clicking the tray icon to restore the window often fails. The issue is intermittent but reproducible.

Investigation shows the D-Bus StatusNotifierItem interface becomes completely unresponsive when this happens — calls to Activate and even basic Ping timeout:

$ gdbus call --session --dest=":1.3349" --object-path="/StatusNotifierItem" \
    --method org.kde.StatusNotifierItem.Activate 0 0
Error: Timeout was reached

$ dbus-send --session --dest=":1.3349" --print-reply --reply-timeout=1000 \
    /StatusNotifierItem org.freedesktop.DBus.Peer.Ping
Error org.freedesktop.DBus.Error.NoReply: Did not receive a reply.

The tray icon remains visible and registered with the StatusNotifierWatcher, but Notion stops processing D-Bus messages entirely. The right-click context menu also fails to respond.

Steps to reproduce

1. Launch notion-electron
2. Minimize window (sends to tray via the hide() call)
3. Work in other applications for a few minutes
4. Click tray icon to restore — no response
5. Right-click tray icon — context menu doesn't appear

Possible cause

Looking at the source code:

1. index.mjs intercepts minimize and calls mainWindow.hide() instead:

mainWindow.on('minimize', function (event) {
    event.preventDefault();
    mainWindow.hide();
});

2. The app uses a custom D-Bus implementation (@clebert/node-d-bus) via lib/dbus.mjs rather than Electron's built-in mechanisms.

The D-Bus message processing may be getting blocked or starved when the Electron window is hidden, causing the StatusNotifierItem interface to stop responding to Activate calls from the tray.

Workaround

Currently none — when this occurs, the only option is to kill and restart the application.

[locomot1f]

I'm seeing the same thing.
For me, when I minimize the window, and then try to reopen it, it crashes on its own.

[anechunaev]

At first glance it looks like incompatibility of the new version of Electron with Wayland protocol. I will continue the investigation, for a quick workaround try to run previous version.

By any chance, do you see the same issue with other Electron apps, like Discord, Steam or Slack?

Some logs for myself

[113854:1212/152308.530130:ERROR:ui/ozone/platform/wayland/host/wayland_wp_color_manager.cc:273] Unable to set image transfer function.
[113854:1212/152308.530142:ERROR:ui/ozone/platform/wayland/host/wayland_wp_color_manager.cc:191] Failed to populate image description for color space {primaries:BT709, transfer:SRGB, matrix:RGB, range:FULL}
[113854:1212/152332.814373:FATAL:ui/ozone/platform/wayland/host/wayland_toplevel_window.cc:791] Should not be called with kMinimized state

[faasie]

@anechunaev - Let me check with some of the other Electron apps. Will let you know.

[faasie]

Additional Testing Results

I tested another Electron app on the same system to help narrow down where the issue might be.

D-Bus Responsiveness Comparison

App	Electron Version	Ping	Activate
Discord (Flatpak)	37.6.0	5ms ✓	7ms ✓
Notion 1.9.2	?	4ms ✓	25s timeout ✗
Notion 1.9.3	?	timeout ✗	timeout ✗

What This Might Mean

• Discord's tray icon works perfectly on my Wayland/GNOME setup, so the AppIndicator extension and underlying stack seem fine
• Notion 1.9.2 responds to Ping instantly, but Activate (the tray click) times out
• Notion 1.9.3 has both timing out, which matches your suspicion about something changing

I'm not a developer so I can't dig deeper, but hopefully this data helps point you in the right direction! Happy to run any other tests if useful.

Test Commands (for reference)

# Ping
gdbus call --session --dest=":1.xxx" --object-path="/StatusNotifierItem" \
    --method org.freedesktop.DBus.Peer.Ping

# Activate (tray click)
gdbus call --session --dest=":1.xxx" --object-path="/StatusNotifierItem" \
    --method org.kde.StatusNotifierItem.Activate 0 0

[anechunaev]

@faasie, that's helpful, thank you!

[faasie]

Update: Issue also occurs on 1.9.2

After running 1.9.2 for a few hours, the same issue occurred — the tray icon becomes completely unresponsive.

Progression of the issue:

1. App works fine initially
2. After some time minimized to tray, D-Bus stops responding (both left-click and right-click fail)
3. Eventually the app crashes entirely

So it appears to be time-based rather than version-specific. Something is degrading while the app is minimized until the D-Bus interface freezes, and then it crashes.

The process appears normal right up until the crash — it's specifically the D-Bus/tray communication that freezes first.

[anechunaev]

Fixed in v1.9.4