How to reproduce: * Be in konsole * Make sure konsole has keyboard focus * Right click in konsole window decoration * Popup menu appears * Left click outside the popup menu in the konsole window * Popup menu closes * konsole doesn't have keyboard focus
Can't confirm for the moment. a) Does konsole also become inactive interim (check titlebar text color)? b) What if you close the menu pressing escape? c) What activation model do you use ("click to focus", "focus follows mouse", "focus under mouse", "focus strictly under mouse")? d) Does this happen with aurorae/breeze or oxygen decoration (or both)?
a) No, it still has the "dark" color, so i guess it's not inactive b) Then it works, nothing goes wrong c) Click to focus d) Both Not sure it matters, but i can click as many times i want on the konsole window and text focus doesn't come back, i can even select text and then alt+tab to another window and middle click paste it
Also it's not konsole specific, kate has the same problem (both still Qt4 based) *but* if i try with gedit there is no problem.
It might be related to: https://codereview.qt-project.org/99587
It apparently only seems to affect Qt4 clients (but i cannot reproduce it here) Albert, does it also happen for "kate --style plastique"?
Yes, still happens for kate --style plastique
Any other i can help debugging this, it's pretty bad for me at the moment, i also have this focus problem with qt4 apps only with the screen locker (i.e. coming back from the screen locker the app loses focus)
(In reply to Albert Astals Cid from comment #7) > i.e. coming back from the screen locker the app loses focus Sorry, I don't follow. Is this somehow related to bug #341201 or do you mean to say "this problem only starts after having locked the screen once"?
> Is this somehow related to bug #341201 No > do you mean to say "this problem only starts after having locked the screen once"? Neither I say i have the same problem when returning from a locked screen, the focus is lost from the app that had it (only for qt4 based apps it seems)
Created attachment 89704 [details] am_i_focused.cpp Are they equally "inactivatable" (by clicking into them)? This sounds as if they a) either didn't get that they lost the input focus b) start to deny taking input focus after "sth. else" has grabbed the mouse => please dump xwininfo and xprop on such client in this state and attach them here. Also there's a mini test app attached that will print whether Qt believes it's the active window when clicking into it.
Ah, sorry this shows the screen locker and the decoration thing are two actually different bugs, since when coming back from the screen locker the focus is lost but clicking on the window it comes back, but while the decoration context menu it does not, i'll file a separate bug for the screen locker one, should it be kwin or kscreenlocker? Let's focus in the decoration context menu issue in here. The debug is false. xwininfo and xprop seem to give the same output in the "normal" state and in the "click won't give me focus" state. xwininfo: Window id: 0x6600003 "a.out" Absolute upper-left X: 301 Absolute upper-left Y: 217 Relative upper-left X: 0 Relative upper-left Y: 0 Width: 256 Height: 192 Depth: 24 Visual: 0x20 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x22 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +301+217 -1363+217 -1363-671 +301-671 -geometry 256x192+299+194 xprop _NET_WM_USER_TIME(CARDINAL) = 1741419 _NET_WM_ICON_GEOMETRY(CARDINAL) = 1059, 1054, 250, 26 _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE _KDE_NET_WM_FRAME_STRUT(CARDINAL) = 2, 2, 23, 4 _NET_FRAME_EXTENTS(CARDINAL) = 2, 2, 23, 4 _NET_WM_DESKTOP(CARDINAL) = 0 _KDE_NET_WM_ACTIVITIES(STRING) = "443c42b8-85f4-45af-8876-abbbcc86d7e7" WM_STATE(WM_STATE): window state: Normal icon window: 0x0 _NET_WM_STATE(ATOM) = _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 106954763 _KDE_OXYGEN_BACKGROUND_PIXMAP(CARDINAL) = 0 _KDE_OXYGEN_BACKGROUND_GRADIENT(CARDINAL) = 1 XdndAware(ATOM) = BITMAP _MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0, 0x0 WM_CLIENT_LEADER(WINDOW): window id # 0x6600005 _NET_WM_PID(CARDINAL) = 5143 _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x3e, 0x7e, 0x0, 0x0 WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST _KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 1676946 WM_NAME(STRING) = "a.out" WM_LOCALE_NAME(STRING) = "ca_ES.UTF-8" WM_CLASS(STRING) = "a.out", "A.out" WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. window id # of group leader: 0x6600005 WM_NORMAL_HINTS(WM_SIZE_HINTS): window gravity: NorthWest WM_CLIENT_MACHINE(STRING) = "xps" WM_COMMAND(STRING) = { "./a.out" }
> The debug is false. Ok, the window believes it's not the active one. > Class: InputOutput Fine. > Override Redirect State: no Fine. > _NET_WM_USER_TIME(CARDINAL) = 1741419 Fine. > _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 106954763 At least looks ok. > WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST Fine. > Client accepts input or input focus: True Fine. Blast. Ok, does the window receive the input events? $ xev -id 0x6600003 -event keyboard You'll have to update the win #id of course. If this prints keyboard events when "notactivating" the window, yet the client does not react, it's sth. in the Qt4 event dispatcher (the window actually does have the input focus, but Qt4 does somehow not handle it)
Yes it does receive the keyboard events. I did xev over the window and i am getting this when right clicking on the decoration LeaveNotify event, serial 20, synthetic NO, window 0x2c0001a, root 0x90, subw 0x0, time 3941596, (469,-1), root:(880,68), mode NotifyNormal, detail NotifyNonlinear, same_screen YES, focus YES, state 0 FocusOut event, serial 20, synthetic NO, window 0x2c0001a, mode NotifyGrab, detail NotifyNonlinear FocusOut event, serial 20, synthetic NO, window 0x2c0001a, mode NotifyWhileGrabbed, detail NotifyNonlinear EnterNotify event, serial 20, synthetic NO, window 0x2c0001a, root 0x90, subw 0x0, time 3948810, (528,427), root:(939,496), mode NotifyUngrab, detail NotifyNonlinear, same_screen YES, focus NO, state 256 KeymapNotify event, serial 20, synthetic NO, window 0x0, keys: 39 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 FocusIn event, serial 20, synthetic NO, window 0x2c0001a, mode NotifyNormal, detail NotifyPointer I know nothing about X so this may be silly, but do we need two FocusIn if we get two FocusOut?
(In reply to Albert Astals Cid from comment #13) > I know nothing about X so this may be silly, but do we need two FocusIn if > we get two FocusOut? No, but in theory there should not be two FocusOut's in a row either (so an overly "smart" counter would fail on this) Thing is, that it doesn't happen here - what about: kwin_x11 --replace --style fusion & (I'm running virtuality, tested fusion, have no Oxygen/Qt5 installed atm)
You know what's funny? A simple kwin_x11 --replace & fixes it. So i can only reproduce it when loggin in, after that restarting kwin_x11 i can't reproduce the issue anymore :S
(In reply to Albert Astals Cid from comment #15) > A simple > kwin_x11 --replace & > fixes it. Let's try to pin the technical causes: a) how many FocusOut's do you get after the restart (ie. w/o the bug)? b) did the "look" of the context menu somehow change (oxygen <-> breeze <-> fusion)? In case the answer to (a) is "one" and in doubt of (b), just make screenshots (use the delay function) of the popups before and after.
(In reply to Thomas Lübking from comment #16) > Let's try to pin the technical causes: > a) how many FocusOut's do you get after the restart (ie. w/o the bug)? Just one. > b) did the "look" of the context menu somehow change (oxygen <-> breeze <-> > fusion)? They do not change, both with and without the bug it's oxygen.
could you please try again? It might be that with the change to kdecoration2 the problem is fixed (at least I cannot reproduce given the instructions from comment #0).
Try with which version?
(In reply to Albert Astals Cid from comment #19) > Try with which version? current master (5.2)
Is it easy to compile andtry kwin master only? Or do i need some other stuff? Otherwise i think i'll have to wait for my distro to update the packages.
You'll also - require an up-to-date kwindowsystem (unless you revert a patch in kwin) and - that will require ecm 1.6.0 (though i could build on 1.5.0 when maipulating the cmake check) But that should do.
PS: you'll probably have to build kdecoration as well, sorry.
This is still happening to me with 5.1.95 packages.
might also be related to https://bugreports.qt.io/browse/QTBUG-43776
*** Bug 343487 has been marked as a duplicate of this bug. ***
So i don't have a qt4 based konsole or kate anymore to test but i tried with qt4 okular and qt4 assistant and the bug seems gone, so let's close it as works for me.