Mutter on Wayland makes incorrect assumption about StartupNotify key in desktop entries
Affected version
Fedora 32
mutter 3.36.3
Wayland
Bug summary
Let's say that there is an app with StartupNotify=true in its desktop entry, and this app does not use GTK+ but does support Wayland natively (as well as X).
When GNOME Shell on X11 launches this app (via mutter), it sets DESKTOP_STARTUP_ID and shows busy cursor. When this app shows its window, it sends "remove" message according to Startup Notification Protocol and GNOME Shell hides busy cursor. Everything works as it should work.
When GNOME Shell on Wayland launches this app (via mutter), it also sets DESKTOP_STARTUP_ID and shows busy cursor. Then it waits when this app will call a specific method of private GTK+ / GNOME Shell protocol or timeout expires. This, however, won't happen because this app is not based on GTK+ and doesn't know about this protocol - and it shouldn't.
As per Desktop Entry Specification:
StartupNotify - If true, it is KNOWN that the application will send a "remove" message when started with the DESKTOP_STARTUP_ID environment variable set. If false, it is KNOWN that the application does not work with startup notification at all (does not shown any window, breaks even when using StartupWMClass, etc.). If absent, a reasonable handling is up to implementations (assuming false, using StartupWMClass, etc.). (See the Startup Notification Protocol Specification for more details).
Startup Notification Protocol Specification says:
The startup notification protocol involves sending X messages with the message_type atom _NET_STARTUP_INFO_BEGIN/_NET_STARTUP_INFO to the root window.
It is completely clear for me, an application developer, that Startup Notification Protocol is X-specific protocol and StartupNotify key in desktop entry is X-specific and therefore should do nothing on Wayland. Nowhere in these specifications it says that StartupNotify key requires use of some private Wayland protocol. Placing this additional requirement on my application is clear violation of these specifications.
Steps to reproduce
- Launch any non-GTK app with StartupNotify=true in its desktop entry on GNOME Wayland.
- Observe busy cursor on GNOME Shell for 15 seconds.
What happened
Mutter expected my application to know about some private Wayland protocol based on desktop entry key that has nothing to do with said protocol.
What did you expect to happen
Mutter shouldn't have assumed that my application knows anything about its private protocols.