Add focus/unfocus event passing for Xmir non-rootless mode

[Daniel van Vugt]

[Impact]

This will allow copy & paste to work with X apps on desktop systems using U8.

[Test Case]

1. Compile & install the Libertine branch found here:
https://code.launchpad.net/~townsend/libertine/pasted/+merge/299603
2. Create a Libertine container.
3. Install an X app in the Libertine container and start it.
4. Copy text in the X app.
5. Paste it in a native U8 app.

[Regression Potential]

Non observed.

-----------------------------------------------------------
Original Description:

Add focus/unfocus event passing for non-rootless mode

[Daniel van Vugt (vanvugt)]

Wait, does this request make any sense? (Brandon?)

The described use case was wanting to hide the OSK on focus loss. But surely you only want to hide the OSK when the text widget loses focus.

So implementing this may stop the OSK from staying on screen after an app switch (assuming Unity8 does not SIGSTOP the app, in which case this is more pointless). But it won't solve the OSK staying on screen after you've finished entering text. That's the job of the input method's toolkit backend to signal that the input field is finished.

If the only remaining purpose of this request is to hide the OSK on app switch, is it really necessary? Surely it's the shell's job to automatically hide the OSK on app switch... And surely if Unity8 is in the habit of SIGSTOP'ing apps when they lose focus then Xmir acting on loss of focus is impossible anyway. Because the Xmir process would be frozen.

[Brandon Schaefer (brandontschaefer)]

Should make sense. Whats needed is when a window losses focus, ie. its no longer on the top of the stack. This is the broken part.

The input area lossing focus... i need to double check. I know the qt apps were working the that respect but the gtk apps i tested were all text editing :)

[Daniel van Vugt (vanvugt)]

Does "a window" mean an X window or Mir window?

This request only makes sense for the former. Because an X app popping up a dialog or menu should indeed change the OSK state. However that is 100% inside X and Mir windows have nothing to do with it. That is also the job of the toolkit input method backend to handle. Focus logic within Xorg is not something Xmir should ever touch.

As for Mir windows losing focus, that's not a sensible request either. Even if you disagree it's the shell's job to hide the OSK on app switching, you still have the problem of: apps can't respond to loss of focus on the phone. Because we freeze them for power savings, don't we? Or is the SIGSTOP delayed?

[Brandon Schaefer (brandontschaefer)]

The thing is, the shell does tell the osk to hide or rather it gives enough info off that the window should know that its time to hide. Im assuming this is true based on U8 window normally hide when you click on a different window or a new window is mapped above it. The only issue seems to be LXC/XMir windows?

Shouldnt this mean, in xmir if we get a loss of focus we should tell the window it so the toolkits know we've lost focus? Not sure how else the toolkits will know they've lost focus?

[Daniel van Vugt (vanvugt)]

"Windows" losing focus is seemingly not a sensible problem to worry about.

In windowing/desktop mode you are expected to have a physical keyboard. So there is no OSK that should ever be displayed. And no OSK to hide.

In phablet touch mode, you do occasionally need an OSK. But we SIGSTOP apps when they lose focus, so telling the app it has lost focus in pointless -- it's frozen and will never notice it lost focus until it regains focus and gets unfrozen (SIGCONT).

[Daniel van Vugt (vanvugt)]

Unless....... opening the switcher means an app loses focus before it gets SIGSTOP'd. Then the request is plausible, but still not sensible. Not sensible because the Unity8 shell should be smart enough to automatically hide the OSK when the switcher opens.

I don't yet see any logical way forward for this enhancement request. It's either useless or should be implemented by Unity8 itself.

[Brandon Schaefer (brandontschaefer)]

I just got the OSK working on the phone... and again the *focus* is never lost. Mainly the issue being when the phone locks. You turn the screen back on and the osk is still open for the lxc application. You can still type to it and it all goes to that app. Need to figure something out for this...and it does appear to be an xmir issue?

[Daniel van Vugt (vanvugt)]

This is correct behaviour. The X server window loses focus, not the X app inside it.

Your app would lose focus correctly if Unity8 used Xmir properly with -rootless. I appreciate Unity8's still not ready for that (bug 1543467) so will implement another workaround in Xmir.

[Daniel van Vugt (vanvugt)]

Oops. The /correct/ use case for -rootless was never implemented. Although Unity8 doesn't use that yet, it would be the simple case to deal with first before addressing this enhancement.

[Daniel van Vugt (vanvugt)]

Done.
Finished in: https://git.launchpad.net/~xmir-team/xorg-server/+git/xmir/commit/?id=2deb8ecbe9c896d6e32df505b8ee20d08fc29d0c
To see the full implementation (several commits worth): git diff c45845cb28..2deb8ecbe

NOTE: Focus switching is only implemented in -rootless mode or rooted mode with -title @. Since the feature is something of a heuristic, it is disabled by default for pure rooted mode. However the focus switching is automatically enabled when you use '-title @' which is a similar hack that we use for Unity8 right now.

[Launchpad Janitor (janitor)]

This bug was fixed in the package xorg-server - 2:1.18.3-1ubuntu6

---------------
xorg-server (2:1.18.3-1ubuntu6) yakkety; urgency=medium

  * debian/patches/xmir.patch:
    - Add focus/unfocus event passing (LP: #1582471)

 -- Robert Ancell <email address hidden> Wed, 01 Jun 2016 11:07:46 +1200