Bug 340996

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.