Bug 500696

Summary:	Menu highlight can go briefly out of sync with pointer position when cursor is rapidly moved up and down
Product:	[Plasma] plasmashell	Reporter:	cwo <cwo.kde>
Component:	Application Menu (Kicker) widget	Assignee:	Plasma Bugs List <plasma-bugs-null>
Status:	RESOLVED FIXED
Severity:	minor	CC:	aspotashev, nate
Priority:	NOR
Version First Reported In:	master
Target Milestone:	1.0
Platform:	Other
OS:	Linux
Latest Commit:	https://invent.kde.org/plasma/plasma-desktop/-/commit/adae4b08fa73d5dc75cce41791a39c91ac356168	Version Fixed/Implemented In:	6.6.0
Sentry Crash Report:

Description cwo 2025-02-24 21:34:38 UTC

SUMMARY

When moving the pointer rapidly up and down the menu, the highlight and pop-up submenus can go out of sync.

The highlight for similar menu plasmoids is instant. We should see if we can make this more efficient, and if not, only show the menu after a very short delay on hover, like the menus in QWidgets apps do


STEPS TO REPRODUCE
1.  Click the kicker icon
2.  Move the mouse up and down the list

OBSERVED RESULT

Highlight out of sync with pointer

EXPECTED RESULT

Highlight immediately follows pointer

SOFTWARE/OS VERSIONS
KDE Plasma Version:  master
KDE Frameworks Version:  master
Qt Version:  6.8.2

ADDITIONAL INFORMATION

Split from bug 500442.  Confirming directly based on comment 8 there.

Comment 1 cwo 2025-05-17 18:48:34 UTC

*** Bug 504406 has been marked as a duplicate of this bug. ***

Comment 2 Bug Janitor Service 2025-09-03 13:59:31 UTC

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/3176

Comment 3 cwo 2025-11-27 21:11:07 UTC

Git commit adae4b08fa73d5dc75cce41791a39c91ac356168 by Christoph Wolk.
Committed on 27/11/2025 at 20:46.
Pushed by cwo into branch 'master'.

applets/kicker: make submenu behavior more consistent with other menus

Kicker is supposed to mimic the regular (sub)menu behavior in
application menus, but it does not completely do so. For regular
(QtWidgets) menus, if a submenu is open and the user moves to another
entry that has a submenu, there is a slight delay before the new entry
hover-activates and the submenu is replaced. If the user moves to the
submenu and crosses another one, the crossed item is briefly
highlighted, but it snaps back to the original one (where the submenu is
open) as the user reaches the submenu (as long as it happens before the
delay is over).

Kicker is different: while the initial submenu also has a delay, when
one is already is open and the user moves to another item, the submenu
is exchanged immediately. If the user crosses multiple entries, they all
have to be layouted, the submenu resized, etc. only to be immediately
replaced with the next thing the user crosses over. This can cause
visual glitches and slight flickering, and while it is not very
expensive by itself, if it happens many times per second it can cause
noticeable delay where the mouse cursor and menu highlight go out of
sync as Plasma is too busy creating and discarding submenu contents to
follow the cursor (bug 500696). To handle the case of moving the cursor
to a submenu, there is a partially implemented triangle mouse filter
that works rather inconsistently. The implementation for all this is
hard to follow as it is spread across multiple components with lots of
special-casing and internal state tracking and separate timers.

Instead, we have Kicker behave like regular menus, and only replace the
submenu after a small delay. This is more consistent with QtWidgets
menus and avoids the visual noise and slowdowns. It also allows us to
simplify the implementation, reducing the amount of state tracking and
custom behavior while having clearer and more standard code paths.

M +0 -47 applets/kicker/ItemListDelegate.qml
M +1 -0 applets/kicker/ItemListDialog.qml
M +55 -65 applets/kicker/ItemListView.qml
M +0 -2 applets/kicker/MenuRepresentation.qml

https://invent.kde.org/plasma/plasma-desktop/-/commit/adae4b08fa73d5dc75cce41791a39c91ac356168