Bug 436473 - Cursor is stuck to resize icon when hovering into panels across the movable dividers
Summary: Cursor is stuck to resize icon when hovering into panels across the movable d...
Status: RESOLVED FIXED
Alias: None
Product: Breeze
Classification: Plasma
Component: QStyle (show other bugs)
Version: 5.21.5
Platform: Debian unstable Linux
: HI normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords: regression
: 436797 437308 437404 437528 437579 437608 437644 437940 438451 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-05-01 23:06 UTC by tomtomtomreportingin
Modified: 2024-02-16 19:24 UTC (History)
33 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.22


Attachments
video showing the bug (1.29 MB, video/mp4)
2021-05-10 14:44 UTC, S. Christian Collins
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tomtomtomreportingin 2021-05-01 23:06:50 UTC
SUMMARY
The cursor is stuck to a resize icon when traversing across the resizable divider into the panels, blocking regular functionality.

STEPS TO REPRODUCE
1. Cross the cursor across the movable dividers into any panel, most commonly Places.

OBSERVED RESULT
The cursor is stuck to a resize icon.

EXPECTED RESULT
The cursor behaves normally allowing you to actually use the panel.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Debian sid
(available in About System)
KDE Plasma Version: 5.20.5
KDE Frameworks Version: 5.78.0
Qt Version: 5.15.2

ADDITIONAL INFORMATION
This does not happen if the panels are accessed without crossing the dividers. Double-clicking or triple-clicking might remove the resize icon. This does not seem to happen with the split-panel divider.
Comment 1 Méven Car 2021-05-02 17:04:57 UTC
I don't understand what `Cross the cursor across the movable dividers into any panel.` means.

By "cross across" do you mean move over, or drag ?

Could you explain what path your cursor did from which border and components, clicks you did, and the setup you have most notably the panels displayed.

In other words Can you describe more precisely how to reproduce this ?
Comment 2 tomtomtomreportingin 2021-05-02 23:06:14 UTC
Let's take the Places panel for example, which contains your bookmarked folders. If placed to the left of the main view of the current directory, a user can resize the Places panel using the divider between the Places panel and the main view. This divider is what I'm referring to when I say "movable divider". The cursor switches to a sort of resize icon when shifting this divider.

More specific steps to reproduce the buggy behavior:
1. Place cursor over the main view (showing the files and folders of the current directory)
2. Shift the cursor to the left, moving across the divider and into the Places panel to the left of the main view. 

No clicking/dragging is necessary to reproduce. It seems that the cursor will "inherit" the resize icon as it moves across the movable divider seperating the panel and main view. It doesn't always happen, but it happens most of the time for both me and a friend.
Comment 3 Méven Car 2021-05-03 05:59:53 UTC
(In reply to tomtomtomreportingin from comment #2)
> Let's take the Places panel for example, which contains your bookmarked
> folders. If placed to the left of the main view of the current directory, a
> user can resize the Places panel using the divider between the Places panel
> and the main view. This divider is what I'm referring to when I say "movable
> divider". The cursor switches to a sort of resize icon when shifting this
> divider.
> 
> More specific steps to reproduce the buggy behavior:
> 1. Place cursor over the main view (showing the files and folders of the
> current directory)
> 2. Shift the cursor to the left, moving across the divider and into the
> Places panel to the left of the main view. 
> 
> No clicking/dragging is necessary to reproduce. It seems that the cursor
> will "inherit" the resize icon as it moves across the movable divider
> seperating the panel and main view. It doesn't always happen, but it happens
> most of the time for both me and a friend.

Thanks, it is as simple to reproduce as it sounds, and I do reproduce it.

It does not always happen, it is sporadic indeed.

One detail I noticed while experiencing the issue: while hovering the panel the cursor blinks for the arrow cursor to the resize panel cursor.

I reproduce it with dolphin 21.07.70 (master).
Comment 4 Méven Car 2021-05-04 05:48:04 UTC
I had a look at our code regarding Panel and Docking, we don't have any code specific for cursor, so I would guess this is a Qt bug.

I couldn't find one corresponding there :
https://bugreports.qt.io/browse/QTBUG-51779?jql=status %3D Reported AND text ~ "resize cursor dock"
Comment 5 S. Christian Collins 2021-05-10 14:44:52 UTC
Created attachment 138289 [details]
video showing the bug

I have attached a video of the bug, recorded from a KDE neon User Edition VM, fully up to date (Dolphin 21.04.0, Plasma 5.21.5, Frameworks 5.81.0, Qt 5.15.2).

Here are my observations about this bug's behavior:
1. The bug occurs after the cursor has traveled from the file view, across the divider to the Places panel, and then outside of the left boundary of the window. After this, moving from right to left across the aforementioned divider will cause the cursor to flash between a resize cursor and a regular mouse pointer, and it will be next to impossible to click anything in the places panel.
2. If you move the mouse very quickly across the divider, the bug does not occur; only slow or medium speed mouse movements trigger the bug.

In the attached video, you will see the following in order:
1. Cursor crosses divider, but does not leave the Dolphin window: NO BUG
2. Cursor finally leaves the Dolphin window, comes back and crosses from right to left over the divider: BUG
3. Cursor moves very quickly over the divider: NO BUG
4. Cursor moves slowly over the divider: BUG
Comment 6 Metal 2021-05-10 21:11:54 UTC
I used the command: sudo apt-get --reinstall dolphin

It works for me!
Comment 7 Metal 2021-05-10 21:20:39 UTC
(In reply to Metal from comment #6)
> I used the command: sudo apt-get --reinstall dolphin
> 
> It works for me!

In fact, when I reinstalled it was working, but the problem remains.
Comment 8 Méven Car 2021-05-11 05:28:50 UTC
(In reply to Metal from comment #7)
> 
> In fact, when I reinstalled it was working, but the problem remains.

Reinstalling dolphin won't change a thing indeed.

I believe the bug is X11 only, according to my testing in Wayland the bug does not occur. Can anyone else confirm ?
Comment 9 Alexander M. 2021-05-11 08:36:20 UTC
I just tested on Wayland (with Nvidia) and the issue is still present and just as easily reproduced.

Also, I'm on Arch and I first had this appear some 10 days or so ago with Plasma 5.21.5, Dolphin 20.12.3 and Frameworks 5.81, while everything worked properly before, so the only common denominator between my system and the OP's is indeed Qt 5.15.2.
Comment 10 francisco_t 2021-05-13 16:46:46 UTC
*** Bug 436797 has been marked as a duplicate of this bug. ***
Comment 11 Anthony Fieroni 2021-05-13 18:14:10 UTC
I can't reproduce it. Did you guys have KDE Qt patches? I'm on Dolphin 21.04.1 (KaOS), i use it all day long since it's my working environment.
Comment 12 Alexander M. 2021-05-13 18:56:06 UTC
I'm on Arch so I have all the latest updates including the patched Qt, and I can still very easily reproduce it. The OP on the other hand is on Debian, which probably (?) means that they have a non-patched Qt, which would mean that the KDE patches are not really a factor here.
Comment 13 Nick Stefanov 2021-05-13 20:01:49 UTC
Same problem on my end with up to date Arch and it's very inconvenient. I often can't click on my side panel or in Dolpin's built-in terminal. If you want to reroduce it with 100% success, try to move the mouse slower.

https://i.imgur.com/nOGFPj1.png
https://i.imgur.com/PhLuImS.png
Comment 14 Alexander M. 2021-05-14 11:45:04 UTC
Simple workaround for the time being: just make it a habit to make a little detour and move the cursor into the sidebar from above, that way it will never bug out because the issue arises from hovering the cursor over the sidebar's resize area/border. Also, as a bonus, if you forget and it bugs out on you, just move it up and outside the sidebar for a moment and it will go back to normal.
Comment 15 Nick Stefanov 2021-05-14 12:13:32 UTC
They have to fix it, I don't want to change my habits. And what about for built in terminal? You always hover on the problem area...
Comment 16 Patrick Auernig 2021-05-14 12:33:39 UTC
I have also noticed the same bug in Krita when moving the mouse over to the layers and back to the canvas area.
Comment 17 Metal 2021-05-14 14:36:59 UTC
(In reply to Anthony Fieroni from comment #11)
> I can't reproduce it. Did you guys have KDE Qt patches? I'm on Dolphin
> 21.04.1 (KaOS), i use it all day long since it's my working environment.

Here 21.04.0

I can reproduce this bug in Krita software too, not only in Dolphin! So, it can be hard to find this error.
Comment 18 Metal 2021-05-14 14:48:24 UTC
(In reply to Alexander M. from comment #12)
> I'm on Arch so I have all the latest updates including the patched Qt, and I
> can still very easily reproduce it. The OP on the other hand is on Debian,
> which probably (?) means that they have a non-patched Qt, which would mean
> that the KDE patches are not really a factor here.

It coud be a QT or KDE Frameworks problem?

Here:
KDE Frameworks 5.81.0
Qt 5.15.2 (compiled 5.15.2)
Comment 19 Alexander M. 2021-05-14 16:04:23 UTC
(In reply to Metal from comment #18)
> (In reply to Alexander M. from comment #12)
> > I'm on Arch so I have all the latest updates including the patched Qt, and I
> > can still very easily reproduce it. The OP on the other hand is on Debian,
> > which probably (?) means that they have a non-patched Qt, which would mean
> > that the KDE patches are not really a factor here.
> 
> It coud be a QT or KDE Frameworks problem?
> 
> Here:
> KDE Frameworks 5.81.0
> Qt 5.15.2 (compiled 5.15.2)

Well in theory yes, but barring for the moment the possibility that it's a combination of different factors and different components, I'd say it's not the KDE Frameworks because OP experienced this issue with version 5.78 while I first experienced it with 5.81.

It also can't be the KDE patches for Qt, because OP is on Debian Sid and AFAIK the Qt package there does not carry the KDE patches (unless OP is using a custom, patched Qt package).

On the other hand, now that I think about it, it can't be Qt on its own either, as I proposed before, because we've been on version 5.15.2 for ~5 months now already and this issue has only been a problem for the last couple weeks or so.

And it can't be Dolphin because on Arch we're on 20.12.3 since March and OP is on Dolphin 20.12.2, which didn't produce any issues on Arch.

Just for completeness' sake it also can't be Plasma, because OP is on version 5.20.x and here on Arch we're on 5.21.x.

So apparently it's neither Plasma, nor the KDE Frameworks, nor Qt, nor the KDE patches for Qt, nor Dolphin, at least not on their own.

Bummer.

PS - Of course, take all this with a grain of salt as I have no clue about how the KDE code base actually works, not to mention I may have made a mistake with all these combinations of different versions and components.
Comment 20 Christoph Feck 2021-05-14 22:55:14 UTC
Breeze style uses a hack to enlarge the area for the splitter. If this issue disappears when running Dolphin with "-style Windows", then it is a Breeze bug.
Comment 21 ConnorK 2021-05-14 23:52:39 UTC
Hi, I just discovered this bug is present in Krita as well when moving the cursor to the clickable tools on the left side. https://i.imgur.com/VCgVtbg.png

Arch Linux
Krita 4.4.3
KDE Plasma Version 5.21.5
Frameworks 5.82.0
Qt: 5.15.2
on X11
Comment 22 tomtomtomreportingin 2021-05-15 00:06:37 UTC
(In reply to Christoph Feck from comment #20)
> Breeze style uses a hack to enlarge the area for the splitter. If this issue
> disappears when running Dolphin with "-style Windows", then it is a Breeze
> bug.

I believe you are correct. Not only does the behavior not happen with Windows style, it also aligns well with the timeframes. In Debian sid on April 12th, Breeze received an update that included a cherrypicked fix for https://bugs.kde.org/show_bug.cgi?id=431921 .

According to that bug report and the diffs, I am going to guess the commits in question that caused this behavior result from https://invent.kde.org/plasma/breeze/-/merge_requests/95#note_721d4e8f91346cf2b91b3660853ce0ccd87db9b2 .
Comment 23 Nate Graham 2021-05-15 00:14:19 UTC
Seems quite suspicious indeed.
Comment 24 Alexander M. 2021-05-15 07:20:22 UTC
Probably (re)stating the obvious here, but Arch also received an update to Breeze on May 4th, and that fits with my being annoyed by this issue for about a week or so before I came here to report it on May 11th (but instead I found this bug report).

Also, yes, -style Windows/Fusion does remove the issue, while -style Breeze reintroduces it.
Comment 25 Nick Stefanov 2021-05-15 07:46:04 UTC
You are a genuis!!!
With MS Windows 9x selected, the problem is gone!

But it's very ugly :D
Comment 26 Nick Stefanov 2021-05-15 07:48:25 UTC
Hmm, actually every other style than Breeze fixes the problem.
Comment 27 Fabian Vogt 2021-05-15 10:03:37 UTC
(In reply to tomtomtomreportingin from comment #22)
> (In reply to Christoph Feck from comment #20)
> > Breeze style uses a hack to enlarge the area for the splitter. If this issue
> > disappears when running Dolphin with "-style Windows", then it is a Breeze
> > bug.
> 
> I believe you are correct. Not only does the behavior not happen with
> Windows style, it also aligns well with the timeframes. In Debian sid on
> April 12th, Breeze received an update that included a cherrypicked fix for
> https://bugs.kde.org/show_bug.cgi?id=431921 .
> 
> According to that bug report and the diffs, I am going to guess the commits
> in question that caused this behavior result from
> https://invent.kde.org/plasma/breeze/-/merge_requests/
> 95#note_721d4e8f91346cf2b91b3660853ce0ccd87db9b2 .

Yep, I can reproduce the bug here, but only when moving the cursor down inside the terminal panel, not for the vertical divider to the places panel at the side. The issue disappears when reverting cc613558bae7c809e36951da89db3c7cc1a5a58e, I'll have a look.
Comment 28 Bug Janitor Service 2021-05-15 16:03:04 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/breeze/-/merge_requests/102
Comment 29 Fabian Vogt 2021-05-18 10:13:48 UTC
Git commit f99b7ef621c9c69544158d245699fd8104db6753 by Fabian Vogt.
Committed on 18/05/2021 at 06:29.
Pushed by fvogt into branch 'master'.

Fix informing the underlying widget when leaving SplitterProxy

While the SplitterProxy is active, it intercepts all relevant events, so that
the underlying widget still thinks it's in the same "on splitter" state. When
the SplitterProxy is left, the underlying widget is sent a HoverLeave/HoverMove
event to make it aware of the new current cursor position. Without this, it
doesn't know that it's not supposed to be in the "on splitter" state, and when
it regains focus it just re-activates the SplitterProxy at the current cursor
position.

This was broken by accident in d201a1f187 ("Fix SplitterProxy not clearing
when above another QSplitterHandle"), which moved the hide() call past the
call to QCoreApplication::sendEvent. Previously that made isVisible() false,
which also prevented the interception of the HoverLeave/HoverMove events.

M  +7    -4    kstyle/breezesplitterproxy.cpp

https://invent.kde.org/plasma/breeze/commit/f99b7ef621c9c69544158d245699fd8104db6753
Comment 30 Fabian Vogt 2021-05-18 10:14:14 UTC
Git commit 40d558e96d607419b9bfaa9a706621a906bab3e9 by Fabian Vogt.
Committed on 18/05/2021 at 10:14.
Pushed by fvogt into branch 'Plasma/5.22'.

Fix informing the underlying widget when leaving SplitterProxy

While the SplitterProxy is active, it intercepts all relevant events, so that
the underlying widget still thinks it's in the same "on splitter" state. When
the SplitterProxy is left, the underlying widget is sent a HoverLeave/HoverMove
event to make it aware of the new current cursor position. Without this, it
doesn't know that it's not supposed to be in the "on splitter" state, and when
it regains focus it just re-activates the SplitterProxy at the current cursor
position.

This was broken by accident in d201a1f187 ("Fix SplitterProxy not clearing
when above another QSplitterHandle"), which moved the hide() call past the
call to QCoreApplication::sendEvent. Previously that made isVisible() false,
which also prevented the interception of the HoverLeave/HoverMove events.


(cherry picked from commit f99b7ef621c9c69544158d245699fd8104db6753)

M  +7    -4    kstyle/breezesplitterproxy.cpp

https://invent.kde.org/plasma/breeze/commit/40d558e96d607419b9bfaa9a706621a906bab3e9
Comment 31 Fabian Vogt 2021-05-18 10:14:38 UTC
Git commit ae9639f71087ea1e5da1f6ffe29816f0ade84db3 by Fabian Vogt.
Committed on 18/05/2021 at 10:14.
Pushed by fvogt into branch 'Plasma/5.18'.

Fix informing the underlying widget when leaving SplitterProxy

While the SplitterProxy is active, it intercepts all relevant events, so that
the underlying widget still thinks it's in the same "on splitter" state. When
the SplitterProxy is left, the underlying widget is sent a HoverLeave/HoverMove
event to make it aware of the new current cursor position. Without this, it
doesn't know that it's not supposed to be in the "on splitter" state, and when
it regains focus it just re-activates the SplitterProxy at the current cursor
position.

This was broken by accident in d201a1f187 ("Fix SplitterProxy not clearing
when above another QSplitterHandle"), which moved the hide() call past the
call to QCoreApplication::sendEvent. Previously that made isVisible() false,
which also prevented the interception of the HoverLeave/HoverMove events.


(cherry picked from commit f99b7ef621c9c69544158d245699fd8104db6753)

M  +7    -4    kstyle/breezesplitterproxy.cpp

https://invent.kde.org/plasma/breeze/commit/ae9639f71087ea1e5da1f6ffe29816f0ade84db3
Comment 32 Nick Stefanov 2021-05-18 10:17:17 UTC
Many thanks for this! Much appreciated!
Comment 33 Nate Graham 2021-05-18 15:34:14 UTC
*** Bug 437308 has been marked as a duplicate of this bug. ***
Comment 34 Nate Graham 2021-05-20 14:30:54 UTC
*** Bug 437404 has been marked as a duplicate of this bug. ***
Comment 35 Christoph Feck 2021-05-23 05:52:58 UTC
*** Bug 437528 has been marked as a duplicate of this bug. ***
Comment 36 Nate Graham 2021-05-23 22:18:04 UTC
*** Bug 437579 has been marked as a duplicate of this bug. ***
Comment 37 Nate Graham 2021-05-24 14:31:34 UTC
*** Bug 437608 has been marked as a duplicate of this bug. ***
Comment 38 Lua 2021-05-25 23:15:33 UTC
Will this fix be backported to 5.21.5? I'm having this a lot, it severely impacts in usability.
Comment 39 Nate Graham 2021-05-25 23:23:22 UTC
5.21.5 was already released, so it's up to distros to backport it at this point.
Comment 40 Nate Graham 2021-05-26 18:46:16 UTC
*** Bug 437644 has been marked as a duplicate of this bug. ***
Comment 41 Rajinder Yadav 2021-05-26 20:46:02 UTC
Hi what version of KDE is this fixed in? I notice the divider cursor is fixed when I move horizontally across inside of Dolphin. 

However if I open a terminal by pressing "F4" inside Dolphin and I move vertically, the cursor sticks in divider mode for a while as I move the mouse around over the terminal.

I am still seeing the cursor problem inside of Krita.

Here is my current version info:

Operating System: openSUSE Tumbleweed 20210524
KDE Plasma Version: 5.21.5
KDE Frameworks Version: 5.82.0
Qt Version: 5.15.2
Kernel Version: 5.12.4-1-default
OS Type: 64-bit
Graphics Platform: X11
Processors: 16 × AMD Ryzen 7 2700X Eight-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: Radeon RX 570 Series
Comment 42 Rajinder Yadav 2021-05-26 20:50:27 UTC
OK after reading the comments, it looks like this fix hasn't been backported yet and the problem still exists for me.
Comment 43 Nick Stefanov 2021-05-26 20:54:01 UTC
Not only for you, for all of us. I'm waiting impatiently for Plasma 5.22. This bug freaks me out.
Comment 44 Rajinder Yadav 2021-05-26 21:13:29 UTC
Switching Application style to Fusion fixed the problem for me, I got my sanity back. Thanks Alexander M.
Comment 45 ortliebd 2021-05-27 03:38:31 UTC
Unchecking "Enable extended resize handles" on System Settings->Application Style->Breeze->Configure Style... seems to solve the problem.
Comment 46 S. Christian Collins 2021-05-27 04:37:34 UTC
I can confirm this workaround works. Thanks, ortliebd!
Comment 47 Rajinder Yadav 2021-05-27 20:20:15 UTC
I've confirmed ortliebd suggestion works for me.
Comment 48 Lua 2021-05-28 04:27:07 UTC
@Nate Graham

Will this fix be backported to KDE Neon 5.21.5?
Comment 49 Nate Graham 2021-05-28 04:28:29 UTC
See comment 39.
Comment 50 Nate Graham 2021-06-01 20:24:19 UTC
*** Bug 437940 has been marked as a duplicate of this bug. ***
Comment 51 omano 2021-06-05 01:00:09 UTC
I can confirm the workaround works! This was annoying as hell.
Comment 52 Fabian Vogt 2021-06-05 10:01:46 UTC
Please bug your distros to apply the actual fix, which is available for some time now.
Comment 53 Nate Graham 2021-06-11 21:18:07 UTC
*** Bug 438451 has been marked as a duplicate of this bug. ***
Comment 54 Neros 2021-06-11 21:24:44 UTC
I think I made a mistake, I'm very sorry! (I deleted the reference in "See Also")
Comment 55 David Hurka 2021-06-11 22:10:13 UTC
Not a problem, you can undo almost everything through the normal web interface. :)
Comment 56 Germano Massullo 2024-02-16 09:20:03 UTC
Excuse me but this ticket has been marked as fixed just because of a workaround? I am still experiencing it in dolphin-23.08.4 plasma-desktop-5.27.10, qt 5.15.11
Comment 57 Nate Graham 2024-02-16 19:24:41 UTC
The issue was fixed for people using the default settings. What you're describing as a workaround is not a workaround; it's an example of an incompatibility between that setting and what's going on here.