| Summary: | Hover effect on toolbar buttons not working after dragging window from empty area with Qt ≥ 5.11 | ||
|---|---|---|---|
| Product: | [Plasma] Breeze | Reporter: | Michael D <nortexoid> |
| Component: | QStyle | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | andi.schulz, nate, tsujan2000 |
| Priority: | NOR | ||
| Version: | 5.18.3 | ||
| Target Milestone: | --- | ||
| Platform: | Manjaro | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Video of issue | ||
Actually the hover effect anywhere on the window stops working, not just on the toolbar. This may be a Qt issue because now, with Qt 5.15, the drag code uses QWindow::startSystemMove() and yet, the problem exists under both X11 and Wayland. The structure of the drag code is very old (a mouse press sends a mouse move event, which triggers dragging under appropriate conditions, and a mouse release event is sent after the drag is finished) but I couldn't find a problem in it. Cannot reproduce by dragging. By any chance is this happening after you wake the computer up from sleep? I've recently started to encounter an issue with these symptoms, but it happens after waking up the computer. It isn't related to resuming. You should put the mouse cursor over widgets that have a hover effect (like toolbar buttons). Actually, it isn't limited to Breeze; it happens with QtCurve too. It also happened with Kvantum but I added a workaround for X11 to Kvantum. Sadly, the workaround can't be used for Wayland. I recently added 'QWindow::startSystemMove()' to Kvantum for Wayland and dragging had the same problem under Wayland. I even tried sending enter events to no avail. So, I think the problem should be in Qt. As a matter of fact, it started to happen after a Qt upgrade but I don't remember which version. Yeah, if it happens in multiple widget styles, it's almost certainly a Qt bug. Can you file on on their bug tracker and link it in the URL field of this bug report? Thanks! Oh, I'd added a code comment to Kvantum: It started to happen with Qt5.11. Before 5.11, the code worked fine everywhere: Breeze, Kvantum and QtCurve used it with some variations (I think the original code came from QtCurve or Bespin?). I can't report the problem to Qt because they need a code sample to reproduce it and I don't know exactly where the problem is :( If I find the time, I'll try to compare the sources of Qt 5.10 and 5.11. Will add a comment here if I find the cause. After a long search in Qt's code and finding no problem in it, I started to get suspicious of the old dragging code of Breeze/Kvantum/QtCurve and, finally, succeeded in replacing it with another code structure that solved the problem in Kvantum, under both X11 and Wayland, and also under all Wayland compositors. Long story short, with Qt ≥ 5.11, the event filter should be installed on QWindow, not QWidget, and the mouse press event of QWindow should be "eaten up" to start the drag (the long story is in the latest git source 'Kvantum/style/drag/windowmanager.cpp'). The same approach can be used with Breeze (and QtCurve). Any update on this? Happens whenever dragging from an empty area - hover effects completely stop working until you click inside of the window. Looks like this is not an upstream bug after all. |
Created attachment 126819 [details] Video of issue When moving a window by dragging it from an empty space, the hover effect that outlines toolbar buttons stops working. I've attached a video illustrating this.