Version: SVN (using Devel) OS: Linux This may be related to #235251, except that I've run nearly every monthly release since 4.2.4 and only with 4.6.95 is it happening. (4.6.95/4.7-rc2 is my first 4.7 install.) Configured window behavior is: Focus stealing prevention: medium Policy: focus follows mouse Raise with the following delay: *UNCHECKED* Delay focus by: originally 20 ms, upped to 1000 due to this bug Click raises active window: checked Separate screen focus: unchecked Active screen follows mouse: checked (I do have two monitors in stacked orientation using randr, but they're on the same X screen and video card.) Despite the above, the window under the mouse now gets raised. This is very disturbing to my workflow, which has come to depend upon my ability to set one window on top, then focus another (without raising) using the mouse, so I can see and type in the active window thru the semi-transparent inactive window above it, referring to the information in the inactive window while typing in the active window (partially) below it. It worked correctly in 4.6.5, 4.6.4, and in all previous versions I've installed back to 4.2.4 and 3.5 and earlier before that. I know since I developed that workflow back in the 3.5 era, once compositing was available there. Referencing the earlier bug and the possibility it might be compositing/repaint related only and the other window is actually still on top, no. All interaction is with the newly raised window, including modifier-move-window, tooltip popups, typing, etc, even when I'm back in the overlapped area. Attention to this is a urgent since 4.7.0 release is just around the corner. (I often test betas, etc, but even released kde4 was beta or worse thru 4.3, and this is the first pre-release 4.x I've dared to try as a result. But other than this bug, I've been quite impressed with it so far. I definitely agree with the new desktop effects kcm changes!) I haven't tested with a clean user config yet, but I will followup with that later. I decided getting the bug filed was urgent enough in view of the upcoming 4.7 release that I'd file first, and test a clean user config later. Reproducible: Always Steps to Reproduce: Move mouse over another window. Actual Results: New windows is focused (good) but also raised (shouldn't be). Expected Results: New window is focused but remains where it was in the Z-stack. Gentoo ~amd64 no-multilib, with the kde overlay (obviously, for 4.6.95). KDE2 window decorations, oxygen style, older dual dual-core Opteron 290, kernel 3.0-rc7 (direct from mainline git), Radeon 4650 (rv730 chip) running the native xorg driver, mesa-7.11_rc1 (gentoo's -r1), xorg-server-1.10.3, xf86-video-ati-6.14.2, kms mode, classic/non-gallium as kwin locks up gallium HARD (as in, write-LEDs on the hard drives stay on if the system was writing at the time) if effects are on, or even just entering the desktop effects kcm with effects off (but that's another bug not 4.6.95 related, I've never been able to run gallium drivers with kde, here, but the new desktop effects config allowing me to set effects off by default has allowed further investigation =:^).
Playing with the focus and raise delays, I just confirmed that if raise is checked but the delay set longer than the focus delay, raise occurs at the same time as focus. So raise is not immediately when the mouse moves over the new window, and not delayed with the raise-delay (with or without raise checked), but focus and raise occur at the same time, regardless of the raise settings.
Not here - not by default. -> DO YOU USE TILING? ("kcmshell4 kwinoptions", last tab - it triggers such behaviour here. No idea whether that's intended)
(In reply to comment #2) > Not here - not by default. > -> DO YOU USE TILING? ("kcmshell4 kwinoptions", last tab - it triggers such > behaviour here. No idea whether that's intended) Confirmed, it's not default as I tried $KDEHOME moved out of the way and didn't have the issue (after setting focus-follows-mouse, of course, the default is click-to-focus). I've bisected it down to something in the kwin or plasma files in $KDEHOME/share/config, so far. I've restored everthing else and still get expected behavior. As for tiling, no, I don't use tiling normally (only the drag-to-side half/quarter-maximize thing). I can't confirm that specific setting just yet however as I don't know if it's in a file that's restored in this bisect run or not.
please check permissions on the problematic kwinrc and attach it to the bug if it's writable.
Bah heisenbug! It seems to be working perfectly fine, now! It seems to be a heisenbug. Perhaps it was related to some of the other playing around I was doing, testing out the new version. Whatever, can't duplicate it now! Which is weird as I had rebooted several times and still had it, before. But even with all my old config back in place, I can't duplicate it now. Oh, well, heisenbug bug it is! ( http://en.wikipedia.org/wiki/Heisenbug )
I got the same problem
(In reply to comment #6) > I got the same problem Jonas: What version of kde, please, and the distro and distro version while you're at it? Can you confirm whether moving $KDEHOME/share/config ($KDEHOME normally being either ~/.kde or ~/.kde4 , depending on your distro) elsewhere temporarily, for testing, fixes the problem or not? (You'd do the move either from the text console or from gnome or something else, not with kde running.) If moving $KDEHOME/share/config out of the way fixes the problem, does moving it back (also without kde running... you'll need to delete the dir kde created during the test) trigger it again, or does it end up a heisenbug for you as it did for me? If you can reliably trigger and fix it by moving the config dir, then the next thing is to try leaving everything but the kwin and plasma files (in that dir) in place. If you can still reliably trigger and fix it by moving only them, you'll have gotten farther than I did at diagnosing the problem before it disappeared on me. The obvious steps after that would be to narrow it down to just the kwin (probably, or just the plasma) files, and then to the individual file. Once you confirm that you can eliminate and cure it by moving files around, I can reopen the bug. If after that you can get it narrowed down to an individual file, post it here, and you'll have gone a very long way toward getting a fix. I was of course happy to see it gone, but frustrated that I couldn't figure out what it was, but hoping it was just me. Now that you're getting it too, it's obviously NOT just me, but hopefully you can reproduce it better than I was able to, and we can narrow down and ultimately fix this thing! Meanwhile, thanks for the confirmation of my original problem. I really do hope you have more luck narrowing it down than I did, because I really do NOT like problems that disappear without tracing them, since that means they might reoccur at any time and I'd have as little clue about fixing or avoiding them the second time as I did the first! So getting another chance at this bug is something I very much appreciate, too! Duncan
Reproed here, similar settings as described in the OP, except I have focus delay unchecked. My version is 4:4.7.4-0ubuntu0.1. I can also confirm that this is a Heisenbug, as this just started happening after my most recent reboot. I can't reboot at the moment, so I'm just living with the extreme annoyance. This disrupts my workflow severely just like it does yours, Duncan.
kwin --replace & Stupid question: do you use a touchpad?
(In reply to comment #9) > kwin --replace & (Original reporter here.) Thanks. That's a very useful idea I hadn't thought of for possibly tracking it down further, tho with me I had rebooted/restarted-kde several times and had it stay there... until it just disappeared when I tried bisecting and never came back, much to my relief and frustration, both. > Stupid question: do you use a touchpad? I don't. But the guy in comment #8 might. (I use a Logitech wireless keyboard and trackball, sometimes in USB mode, sometimes in PS2 mode, on the machine that had the problem, my desktop/workstation, tho my netbook does have a touchpad, but it was never affected and since I don't keep it near as updated, AFAIK it's still running 4.6, it may never have been exposed to whatever triggered it on my workstation. FWIW I just upgraded the workstation tho so the hardware's newer than it was.) I'd still dearly love to figure out what triggered it, since the fact that others are still getting the problem and I never tracked it down means I'm still at risk for it again, too, not a very comforting thought tho it would mean I'd get another go at it! Duncan
Nope, not using a touchpad. Are you wondering if I was lightly brushing the surface and registering a tap? I'm using a USB mouse exclusively, and I can trigger the bug just by moving my mouse over a window.
Synaptics driver has (likely? / had? / could be ebkac?) a bug which randomly forgets to release the pointer and creates an extra release. What could happen is that there's a client/tool side raise request when the window gets updated. Unfortunately to check this you'd have to adjust the code ... PS: as asked in comment #2 - you'r not using tiling, i assume?