The bug only happens while I'm using Chrome. It does not seem to have something to do with a specific software version of the browser because it was first visibile to me when a new feature was introduced to activities: Remeber the last virtual desktop to be used in an activity and switch to it immediatly. (That means the bug has been around since 4.8.x, right?) Reproducible: Always Steps to Reproduce: 1. Create 2 activities and 4 virtual desktops. 2. Create keyboard shortcuts to the activities (I'm using Meta + F1/Meta + F2). 3. Activity 1: Open an instance of Chrome on desktop 1, desktop 1 must be the active desktop. 4. Activity 2: Open another instance of Chrome on desktop 1, open an instance of Kate on desktop 2, desktop 2 must be the active desktop. 5. Switch activities utilizing the keyboard shortcuts (otherwise it's not reproducible). Actual Results: If you switch to activity 1, Chrome on desktop 1 gets the focus. So far so good. But If you switch to activity 2, Chrome on desktop 1 has the focus, but desktop 2 with Kate is been shown. You'll recognize that the cursor in Kate is not blinking. That meens: If you hit Alt + F4, Chrome on desktop 1 on activity 2 will be closed despite you cannnot see its window. Expected Results: Kate on activity 2, desktop 2 should have the focus. The bug might be related to Bug 283999. I'm using Kubuntu 12.04.
> The bug only happens while I'm using Chrome. This smells suspicious. I cannot reproduce the behavior. Please record: - the excat version of chrome (chromium?) - the use focus policy - the contents of ~/.kde/share/config/kwinrulesrc (you can obfocusate anthing you consider private - if there's such, but please leave all generic rule data including classnames etc.) - since this is about shortcuts: does it also happen with differen shortcuts? (eg Meta+F12 instead of Meta+F1)
Created attachment 74952 [details] kwinrulesrc
> This smells suspicious. :) > - the excat version of chrome Google Chrome 22.0.1229.94 I use (naturally) always the latest version, but the bugs been around for a while (some month). > - the use focus policy What is that? Where can I find information about this policy? > - the contents of ~/.kde/share/config/kwinrulesrc see attachment > does it also happen with differen shortcuts? Also reproducible with Meta + F11/Meta + F12 (at least for me).
Regarding the focus policy … I think I found it in the windo behavior settings, right? Policy: Click to Focus Focus stealing prevention level: Low Click raises active window: checked
I just remembered another, quite clean installation of Kubuntu 12.04 on the same machine. I tried to reproduce the bug described above with exactly the same outcome: Kate does not get the focus. Interessting, because the technical details are a bit different: - KDE 4.8.5 - Chromium (!) 20.0.1132.47 - 2 activities with 2 desktops on each - shortcuts for the activities used: Ctrl + Alt + Q/Ctrl + Alt + W
what happens if you shutdown alls chromium processes and move away ~/.chromium and ~/.config/chromium (just add a .bak suffix or so)?
I removed ~/.config/google-chrome and ~/.cache/google-chrome after closing all processes. No difference after a clean restart. Maybe I should be a bit more specific about some points: (1.) It looks like the Kate window has the focus becaus the font in the window title is not greyed out but black. Anyway, the cursor is not blinking. If the address bar of the browser had the focus before and I type, the search proposals are shown on desktop 2 overlaying the kate window - despite the browser window itself is on desktop 1. (I can redproduce the bug also when the focus is not in the address bar.) (2.) It is very important that an automatic desktop change occurs if you change the activity. Otherwise the bug does not occur. (3.) It is not a Kate problem. I get the same results with e.g. LibreOffice. (4.) I cannot reproduce the problem when I replace Chrome with a different application like Dolphin.
Could a screencast be helpful?
*sigh* It's aparently the client side decoration which causes chromium to be on all activities as it's techincally undecorated (pending kludge in kwin activity handling) -> Setting chromium to use the system titlebar should stop this behavior. Interestingly i could not reproduce this by forcing ("kcmshell4 kwinrules", last tab) no titlebar on xterm and use that instead of chromium. Can you a) confirm the behavior stops using system decorations b) reproduce it using xterm (with "no titlebar" forced to "yes") @Ivan we can remove the "no deco == all activities" kludge for 4.10, can we? FTR: there may still be a kwin bug regarding this - i don't like the comments in updateCurrentActivity() ;-)
> we can remove the "no deco == all activities" kludge for 4.10, can we? It can be tested, but I guess it will lead to problems (plasma dialogues should be on all activities, etc.). The reason behind that "kludge" (we called it a "heuristic" back then :) ) is that the borderless windows are usually special cases - workspace things, fancy media players, ... stuff that don't generally belong to an activity, but are more of out-of-focus work-environment things. I don't really think we should tailor to the applications that don't want to integrate with our workspace. Chromium, fortunately, allows to show the native windeco.
(In reply to comment #10) > The reason behind that "kludge" (we called it a "heuristic" back then :) ) Let's agree on "wonky guessing mechanism" then :-P > is that the borderless windows are usually special cases - workspace things, workspace and esp. plasma things are however under "our" control and can easily use the proper way (tag window) to be on all activities. We can also incorporate the window type (_net_wm_window_type_dock) or the stickiness ("on all desktops") > I don't really think we should tailor to the applications that don't want to > integrate with our workspace. There's also bug #274931 regarding konsole. I would also and frankly not call that "tailoring" Don't get me wrong, hardly even Martin would hate CSD more than me (proof: "x:t:ima"), but atm. we incorporate a completely unrelated condition into the activity state while we a) now thanks to yourself provide rules to control activity settings b) can control it properly for our in-house stuff (afaics the most relevant case) So I would prefer moving from "guess what" to "know what" asap, if kdelibs wasn't fronzen there'd by now be KWindowSystem::setOnActivity() but for now plasma could just incorporate Containment:setOnActivity(), implement it there directly and then move to KWindowSystem later on.
(In reply to comment #9) > a) confirm the behavior stops using system decorations Unfortunately not. I always use Chrome with the system decoration. Now I tried it without the system decoration. Same behaviour. > b) reproduce it using xterm (with "no titlebar" forced to "yes") I don't now if I got it right. But that's what I did: I started xterm instead of Chrome (right?) and forced it not to show the titlebar. I switched the activities using the shortcuts, but the bug did not show up. Neither with nor without the titlebar shown in xterm.
"blast" - ok. I'll monitor events in the CSD case, assuming it'll be the same issue, exposing in general for you.
I experiece this quite often since KDE 4.9.4. Today, I switched to an activity with okular in the front, read the document, and pressed ctrl + q - and firefox in another activity closed down. I often switch to an activity with kmail, and pressing "+" doesn't do anything untill I click the window (except later I find a row of "+"es in konversations input widget... I am using Qtcurve with a setting where maximized windows have no decoration, can that have to do with it? (I will try and test without that setting, which I really like btw ;)
Looks like this does not happen if I disable the decoration hiding for maximized windows in qtcurve (but that is a sad workaround!)
(In reply to comment #15) > Looks like this does not happen if I disable the decoration hiding for > maximized windows in qtcurve (but that is a sad workaround!) Hehe - well, yes. That pretty much explains it and makes it a plain dupe of bug #274931 *** This bug has been marked as a duplicate of bug 274931 ***