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.
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 ?
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.
(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).
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"
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
I used the command: sudo apt-get --reinstall dolphin It works for me!
(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.
(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 ?
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.
*** Bug 436797 has been marked as a duplicate of this bug. ***
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.
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.
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
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.
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...
I have also noticed the same bug in Krita when moving the mouse over to the layers and back to the canvas area.
(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.
(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)
(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.
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.
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
(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 .
Seems quite suspicious indeed.
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.
You are a genuis!!! With MS Windows 9x selected, the problem is gone! But it's very ugly :D
Hmm, actually every other style than Breeze fixes the problem.
(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.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/breeze/-/merge_requests/102
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
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
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
Many thanks for this! Much appreciated!
*** Bug 437308 has been marked as a duplicate of this bug. ***
*** Bug 437404 has been marked as a duplicate of this bug. ***
*** Bug 437528 has been marked as a duplicate of this bug. ***
*** Bug 437579 has been marked as a duplicate of this bug. ***
*** Bug 437608 has been marked as a duplicate of this bug. ***
Will this fix be backported to 5.21.5? I'm having this a lot, it severely impacts in usability.
5.21.5 was already released, so it's up to distros to backport it at this point.
*** Bug 437644 has been marked as a duplicate of this bug. ***
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
OK after reading the comments, it looks like this fix hasn't been backported yet and the problem still exists for me.
Not only for you, for all of us. I'm waiting impatiently for Plasma 5.22. This bug freaks me out.
Switching Application style to Fusion fixed the problem for me, I got my sanity back. Thanks Alexander M.
Unchecking "Enable extended resize handles" on System Settings->Application Style->Breeze->Configure Style... seems to solve the problem.
I can confirm this workaround works. Thanks, ortliebd!
I've confirmed ortliebd suggestion works for me.
@Nate Graham Will this fix be backported to KDE Neon 5.21.5?
See comment 39.
*** Bug 437940 has been marked as a duplicate of this bug. ***
I can confirm the workaround works! This was annoying as hell.
Please bug your distros to apply the actual fix, which is available for some time now.
*** Bug 438451 has been marked as a duplicate of this bug. ***
I think I made a mistake, I'm very sorry! (I deleted the reference in "See Also")
Not a problem, you can undo almost everything through the normal web interface. :)
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
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.
Folks, this bug is still here even on Plasma 6.3.3 - Kf 6.12 - Qt 6.8.2
(In reply to Germano Massullo from comment #58) > Folks, this bug is still here even on Plasma 6.3.3 - Kf 6.12 - Qt 6.8.2 Can' reproduce, if you want to help provide relevant information.
(In reply to omano from comment #59) > (In reply to Germano Massullo from comment #58) > > Folks, this bug is still here even on Plasma 6.3.3 - Kf 6.12 - Qt 6.8.2 > > Can' reproduce, if you want to help provide relevant information. The context is the same as this old bugreport of mine from 2021 https://bugs.kde.org/show_bug.cgi?id=438451 It happened on both Dolphin and other Plasma file pickers
This bug still happens for me too, though it is much rarer after disabling extended resize handles in the Breeze theme settings. The last two times I got the bug to happen, I had just clicked on an entry in the places panel on the left and was quickly moving my mouse to the right over the divider. Seems to perhaps be some timing issue or race condition where an entry in the places panel is activating something at the instant the cursor turns into the resize handle and it gets stuck that way. I can never seem to repro the bug by trying, though... it's always when I'm just working on something, and *bam* it happens.