| Summary: | "Activate, pass click and raise on release" behavior doesn't make a lot of sense when applied to tabs or menus of window lower in the stacking order | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | php4fan |
| Component: | input | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | duha.bugs, friedrich.public.2001, kde, nate |
| Priority: | NOR | ||
| Version First Reported In: | 6.3.4 | ||
| Target Milestone: | --- | ||
| Platform: | Manjaro | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | screenshot | ||
|
Description
php4fan
2025-05-02 17:10:16 UTC
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. *** |