SUMMARY When a window A has focus, and you click on the title bar of another window B, the focus switches immediately when you press the button, not when you release it, which is nice. So for example if you press the button on window B's title bar and start dragging it around, the new window is immediately brought on front as soon as you press, i.e. as soon as you start dragging. On the other hand, if you click anywhere else on window B, something strange happens. At the moment you press, the old window A remains on front, the new window B remains behind, but there's some sort of animation where you seem to see the focus going from A to B. If pressing and holding the button and moving the mouse cursor has some effect on window B (e.g. selecting text, navigating a menu, or dragging the scrollbar to scroll window B), you see that effect, that is, you are already fully interacting with window B, even though it's behind window A. Only when you release the mouse button does window B come on front and clearly fully become the foreground focused window. One particularly absurd situation is the one shown in the attached screenshot, where I pressed and held the button over a menu of the unfocused window B (Filezilla): window B (FileZilla) is behind, window A (Kate) is on the foreground, but window B's menu is on top of window A: this is a completely impossible, nonsensical situation. Any menu, submenu, popup or appendix of any kind belonging to window A should always be strictly on top of A and strictly behind anything that is on top of A. Traditionally, there's always been a tendency to react to clicks on release rather than on press, and I guess there are good reasons beyond pure convention, but in this case, given that: (A) there are very strong reasons for switching focus on press in at least some particular cases, such as the case where you drag a window, and (B) in the remaining cases, a mouse press often initiates some kind of interaction with the newly-clicked window (e.g. text selection, submenu navigation, scrollbar scrolling), there's a very compelling reason for always switching the focus on press rather than on release; or in other words, when the interaction with the new window begins and not when it ends. SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 6.3.4 KDE Frameworks Version: 6.12.0 Qt Version: 6.9.0 Kernel Version: 6.6.85-2-MANJARO (64-bit) Graphics Platform: Wayland Processors: 12 × 12th Gen Intel® Core™ i7-1255U Memory: 15.3 GiB of RAM Graphics Processor: Intel® Iris® Xe Graphics Manufacturer: ASUSTeK COMPUTER INC. Product Name: Vivobook_ASUSLaptop X1502ZA_F1502ZA System Version: 1.0
Created attachment 180885 [details] screenshot screenshot showing a menu belonging to the background window, on top of the foreground window
Filezilla is a GTK app; can you reproduce this with any Qt apps? I can't reproduce it with Kate, for example. Could be a GTK issue.
Yes, I can reproduce with any combination of Kate, Konsole and Dolphin, including with two windows of any one of them.
Could you maybe attach a screen recording that shows this happen with a GTK app and also a Qt app? Does the issue happen in a new clean user account with no customization?
> Does the issue happen in a new clean user account with no customization? I don't know. I don't like creating garbage user accounts on my machine. > Could you maybe attach a screen recording that shows this happen with a GTK app and also a Qt app? I don't see how that would help. Anyway, I have now tested on another machine with Manjaro and I see it doesn't reproduce there. On the affected machine, under "Window Management > Windows Actions > Inactive Inner Window Actions > Left click" I have: "Activate, pass click and raise on release". I never touched that. That must have been the default when I installed Manjaro. On the machine that doesn't have the issue, I have "Activate, raise and pass click" instead (which I also never touched, so it must have become the default at some point, since I installed Manjaro more recently on that machine). All the other settings are identical. However, on the affected machine, if I change the setting to "Activate, raise and pass click", not only it doesn't fix the issue, but it gets worse: now a simple click on an inactive window will make it focused but won't bring it to the front (a situation that should be impossible: e.g. you can type in it without seeing that you're typing!), and only a second click will bring it to the front.
I'm asking you to help me with debugging this by providing more information, since I can't reproduce the issue myself. If you're not willing to do that, then we probably won't find the cause of the issue and you'll be stuck with it either forever, or until a random unrelated change causes it to go away. Please provide the requested information so I can continue to debug this with you. Thanks!
Well I don't have that information. I did all I could to help you. I suggest you work with what you have. I don't have a spare machine to mess with besides the ones I use for my work, and recording screencasts is a pain in the *** because I need to make sure I don't leak any information that I'm not supposed to leak. > If you're not willing to do that, then we probably won't find the cause of the issue and you'll be stuck with it Not just me, every other affected user too. Did you at least try changing " Inactive Inner Window Actions > Left click" to "Activate, pass click and raise on release" ?
(In reply to php4fan from comment #7) > Did you at least try changing " Inactive Inner Window Actions > Left click" > to "Activate, pass click and raise on release" ? Yes, in fact that that's the default setting now. Since I can't reproduce the issue as described, and you aren't able to collect the extra information I've requested, I'm closing the bug report, sorry.
> Yes, in fact that that's the default setting now. That's the default now?? So the default is to raise on release, and yet, with raise on release you don't observe the issue as described? (part of which is the fact that it raises on release). Now I am the one who would like to see a screen recording from you.
Oh, while making a screen recording, I think I managed to reproduce the issue. That's the power of screen recordings. :) Condensed steps to reproduce: 1. Use default click settings 2. Open a window with an in-window menubar 3. Open any other window, and position it over the first window, such that the menubar in the lower window remains visible 4. Click and drag on a menu in the lower window Result: the menu opens over the higher window, but fails to raise the lower window. My understanding of the new default click mode is that this behavior is broadly expected and intentional, to ease drag-and-drop workflows. Of course menus and drag-and-drop are orthogonal use cases, and it doesn't make sense for menus. Re-opening.
> My understanding of the new default click mode is that this behavior is broadly expected and intentional, to ease drag-and-drop workflows. Of course menus and drag-and-drop are orthogonal use cases, and it doesn't make sense for menus. Nor does it make sense for selecting (dragging to select text, or drawing a rectangle for selecting a rectangular region). Nor for scrolling by dragging the scroll bar I think (if one wants to scroll an inactive window behind without bringing it to front, there's the scroll wheel which has its own setting - but I guess this one is debatable - but then again, maybe scrollbar interaction should have its own setting). The only case where I understand it makes sense to wait until release to raise the window, is drag and drop in case you want to drop into the currently active window. Isn't the system able to tell whether you have clicked on something draggable? BTW I see that the other issue where "activate, raise and pass click" is broken is already fixed in 6.4: https://bugs.kde.org/show_bug.cgi?id=501457
(In reply to php4fan from comment #11) > The only case where I understand it makes sense to wait until release to > raise the window, is drag and drop in case you want to drop into the > currently active window. Isn't the system able to tell whether you have > clicked on something draggable? That's a question for the KWin devs, so I'll let them take over from here.
*** Bug 503979 has been marked as a duplicate of this bug. ***