Created attachment 165330 [details] Demo of the window raising issue during drag-n-drop on Wayland SUMMARY Currently, on Wayland session drag-n-drop should be performed without delays, otherwise there is a risk, that some other window will receive focus and raise above the target window (so user will need to use Task Switcher or Task Manager to re-activate required window). When cursor with an item stops movement and holds/hovers over any window, it quickly receives focus and raises. Such unexpected focus change doesn't happen on X11 session. STEPS TO REPRODUCE 1. Launch some application (e.g. Firefox) and maximize its window 2. Launch 2 instances of Dolphin File Manager. Resize and place their windows at some distance from each other (for example, near opposite edges of the screen). Both windows should be visible (raise/float over Firefox window but without activated "Keep Above Others" option) 3. Select file from one Dolphin window and start dragging it to another Dolphin window 4. On a midway, hold cursor over Firefox window OBSERVED RESULT Firefox window receives focus and raises above second/target Dolphin window EXPECTED RESULT Firefox window doesn't "steal" focus when cursor hovers over it SCREENCAST Please see file in attachment or https://youtu.be/jMoGk-C8L_Q SOFTWARE/OS VERSIONS Linux: Fedora Kinoite 40 (Rawhide) KDE Plasma Version: 5.92.0 KDE Frameworks Version: 5.248.0 Qt Version: 6.6.1 ADDITIONAL INFORMATION It's reproducible on older KDE Plasma releases as well (tested 5.24.7 and 5.27.10). Initially, it was reported at https://bugs.kde.org/show_bug.cgi?id=440534 but since this issue has a slight difference (it happens specifically when user holds cursor over window), Nate suggested to create a new bug report.
Can confirm on Neon Testing, Plasma 5.92.90, Frameworks 5.249.0, Qt 6.6.1
> Firefox window doesn't "steal" focus when cursor hovers over it This is the intentional behavior. If the drag pointer hovers over a window, the user likely wants to drop there. The task manager behavior is strange though and perhaps it needs a follow up.
On X11, the drag and drop operation behaves differently because kwin is not in charge of input, x11 clients typically grab input in such cases.
(In reply to Vlad Zahorodnii from comment #2) > > Firefox window doesn't "steal" focus when cursor hovers over it > > This is the intentional behavior. If the drag pointer hovers over a window, > the user likely wants to drop there. I can't agree with that. Most current KDE Plasma users are not robots/machines to perform Drag'n'Drop action with determined speed and accuracy. Especially, we can't expect that from older people, non-experienced users or users with disabilities. I can think of at least 3 cases where the current focus behavior is harmful to usability: 1. Drag'n'Drop file from file manager window to some other application to transfer file (web browser, chat app etc) 2. Drag'n'Drop browser tab to attach it to another browser window 3. Drag'n'Drop item from file manager to the terminal (to quickly get file/folder path) In a perfect world, I would like to avoid "drag-n-drop focus changes" for both maximized and floated windows (like Windows does - https://www.reddit.com/r/kde/comments/fz6as1/a_feature_that_i_really_missed_from_windows_is_it/). This would allow KWin users to perform simple Drag'n'Drop operations without much hassle (e.g. enable/disable "Always on Top"/"Keep above others", tile windows, drag file to the panel, activate Task Switcher etc.)
Re-opening since there's in fact an open and approved merge request that fixes this, so apparently it's not as intentional was was originally believed. :) https://invent.kde.org/plasma/kwin/-/merge_requests/5076
> so apparently it's not as intentional was was originally believed It is. If you hold the cursor over a window, it will be raised. That's intentional.
Sure, but for how long? Raising it almost immediately after the cursor stops moving--which is what this bug report is about--is not intentional, as evidenced by the fact that you approved a merge request to change that. :)
The EXPECTED RESULT talks about no raising window, i.e. matching the behavior on X11 as demonstrated in the linked video. As I understood it, that was about removing/adding option rather than tweaking the timeout. Since the current behavior on Wayland is intentional, I closed the bug report with RESOLVED INTENTIONAL.
(In reply to Vlad Zahorodnii from comment #8) > The EXPECTED RESULT talks about no raising window, i.e. matching the > behavior on X11 as demonstrated in the linked video. As I understood it, > that was about removing/adding option rather than tweaking the timeout. > Since the current behavior on Wayland is intentional, I closed the bug > report with RESOLVED INTENTIONAL. Yes, you're right, the expected result is to match X11 behavior as it provides arguably better usability. As a regular user, I may not be familiar with the codebase (e.g., timer values), what's in charge of input, how X11 clients grab the focus and other technical details of the KWin/X11/Wayland internals. All I know exactly is that Drag-n-Drop in the above-mentioned cases work better on KWin X11 and Mutter Wayland than on KWin Wayland. Surely, increase of the timeout is the welcome change that hopefully will make this issue less noticeable for the majority of users.
Git commit 8d44ece8743dcc32445edd718740905fad5ab661 by Vlad Zahorodnii, on behalf of Xaver Hugl. Committed on 31/01/2024 at 08:41. Pushed by vladz into branch 'master'. input: increase raise timeout for drag and drop to 1s This should be long enough to not happen accidentally, but short enough to not be annoying and discoverable. M +1 -1 src/input.cpp https://invent.kde.org/plasma/kwin/-/commit/8d44ece8743dcc32445edd718740905fad5ab661
Git commit a47d6ffe9b2703c01784212ca47bee927bad5a73 by Vlad Zahorodnii, on behalf of Xaver Hugl. Committed on 31/01/2024 at 08:42. Pushed by vladz into branch 'Plasma/6.0'. input: increase raise timeout for drag and drop to 1s This should be long enough to not happen accidentally, but short enough to not be annoying and discoverable. (cherry picked from commit 8d44ece8743dcc32445edd718740905fad5ab661) M +1 -1 src/input.cpp https://invent.kde.org/plasma/kwin/-/commit/a47d6ffe9b2703c01784212ca47bee927bad5a73