Bug 422096 - Right-click often performs the first action in the context menu on high-DPI displays
Summary: Right-click often performs the first action in the context menu on high-DPI d...
Status: RESOLVED WORKSFORME
Alias: None
Product: krita
Classification: Applications
Component: Usability (other bugs)
Version First Reported In: 4.2.9
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-26 12:04 UTC by Chris Morgan
Modified: 2020-06-25 04:33 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Morgan 2020-05-26 12:04:09 UTC
STEPS TO REPRODUCE
1. Open the timeline panel (as a good example of this problem).
2. Move the mouse cursor over a layer, and press the right mouse button down.
3. Observe the context menu opens (which is wrong by Windows platform standards—it should instead open on mouse up, which would incidentally fix the bug).
4. Also observe that a fair fraction of the time it opens *with the first context menu item (New Layer) selected* (which is hopefully wrong everywhere).
5. Release the right mouse button.

OBSERVED RESULT
The action (New Layer) is performed, if the first item in the context menu is focused. (If that didn’t happen, move the mouse somewhere else and try right clicking again.)

EXPECTED RESULT
The context menu should have opened and stayed open, as I hadn’t moved the mouse at all, but just right clicked.

SOFTWARE/OS VERSIONS
Krita 4.2.9 (x64)
Windows 10
Qt 5.12.7
Hardware: Surface Book, scaling factor of 200%

ADDITIONAL INFORMATION
I suspect that the focusing of the first item in the menu occurs on high-DPI devices only, something to do with rounding of pixel positions so that in some positions it opens the menu less than one logical pixel above and to the left of the cursor, so that the when the menu opens the cursor is already hovering on the first menu item, when it should have been at least one physical pixel above and to the left of it.

This is extremely irritating because it makes right clicking unreliable. However, it can normally be worked around: most laptop touchpads will either have a physical button that you can right-click-and-hold (and then move the cursor before releasing), or have pressing in the bottom right corner of the touchpad act as the right mouse button. But I suspect there are devices out there incapable of right-click-and-hold, which would make this very bad.

On an earlier point: I know Windows conventions: all actions resulting from mouse events (e.g. click button, right click context menu, do something with dragged file, &c.) take place on mouse up, and NEVER on mouse down (I hereby deem beginning dragging something not an action; 😛). I have no idea about other platform standards, least of all KDE. I have kdenlive installed, and it opens some context menus on mouseup (e.g. timeline) and some on mousedown (e.g. project bin). Eww, such inconsistency!
Comment 1 Ahab Greybeard 2020-05-26 13:01:25 UTC
There was a similar problem with right-click on a frame in the timeline docker.
A change to the context menus layout has been made that avoids that and the right-click on layer name problem. This change will be in version 4.3.0.

You can try the public 4.3.0 beta-1 which is available here:
https://krita.org/en/item/first-beta-of-krita-4-3-0-released/
You can use the portable .zip package if you prefer not to update your existing 4.2.9 installation.

Please do that and hopefully modify the status of this bug report.
Comment 2 Bug Janitor Service 2020-06-10 04:33:09 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 3 Bug Janitor Service 2020-06-25 04:33:10 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!