fix(tray): create the dbus menu once the probe succeeds - #5293
Open
Motaphe wants to merge 1 commit into
Open
Conversation
b58018b swapped the makeMenu() call in the "Menu" property handler for an async probe, but menuProbeReady() never calls makeMenu(). That leaves handleClick() as the only call site, so the menu is created and popped in the same block. Dbusmenu loads its layout asynchronously, so the first click gets a menu with no root item yet and logs: LIBDBUSMENU-GLIB-CRITICAL: dbusmenu_menuitem_send_about_to_show: assertion 'DBUSMENU_IS_MENUITEM(mi)' failed GTK then builds a degenerate popup, which pixman reports as "In pixman_region32_init_rect: Invalid rectangle passed". The second click works because the layout has arrived by then. This is a re-regression of 01ad3d9 ("fix(tray): pre-create dbusmenu for tray items"), which fixed the same assertion the same way. Items that do not export com.canonical.dbusmenu still fail the probe and still fall back to ContextMenu, so the intent of b58018b is kept. Closes Alexays#5285 Co-authored-by: awsms <48278661+awsms@users.noreply.github.com>
|
Experienced this myself just now, and it looks like a few people have hit the same path and had Claude or somesuch land on the same fix. Apps I saw the slow (empty-then-populated) right-click menu on: fcitx5, qpwgraph, SVP Manager, which all use a Qt Build is |
This really needs to be reverted. It also causes |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Tray context menus open empty on the first click and only work on the second.
b58018b swapped the
makeMenu()call in theMenuproperty handler for an async probe, butmenuProbeReady()never callsmakeMenu().handleClick()is now the only call site, so the menu gets created and popped in the same block. Dbusmenu loads its layout asynchronously, so the first click gets a menu with no root item yet:That empty menu is the small blank popup users see. The second click works because the layout has arrived.
It is a re-regression of 01ad3d9 ("fix(tray): pre-create dbusmenu for tray items", 2019), which fixed the same assertion by creating the menu at property-set time.
Calling
makeMenu()when the probe succeeds restores that timing. Items that do not exportcom.canonical.dbusmenustill fail the probe and still fall back toContextMenu.The diff is @awsms's from #5285, credited in the commit. They also suggested reverting b58018b outright. I have no strong view, happy to switch this to a revert if you prefer.
Related issues
Closes #5285
Checklist
clang-formatninja -C build)Testing
Hyprland, three SNI items (KDE Connect, Nextcloud, an Electron app).
Before: empty popup on the first click, full menu on the second, with the two log lines above.
After: full menu on the first click, log clean.