Remove breaking pointer constraints functionality
ClosedPublic

Authored by romangg on Sep 3 2018, 10:02 AM.

Details

Summary

With 2694839099c3, 0bd5eff8623d and f0ba436c724e it is now possible to
unconstrain a pointer by killing the client or deactivating the window, for
example by switching the window via the TabBox.

A user should always be able to do it therefore without needing to explicitly
break the pointer constrain as in the past with the Esc key.

Therefore remove the functionality and also remove the OSD announcing it,
which was often shown at the wrong time.

Test Plan

Manually and auto test adapted.

Diff Detail

Repository
R108 KWin
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
romangg created this revision.Sep 3 2018, 10:02 AM
Restricted Application added a project: KWin. · View Herald TranscriptSep 3 2018, 10:02 AM
Restricted Application added a subscriber: kwin. · View Herald Transcript
romangg requested review of this revision.Sep 3 2018, 10:02 AM

This patch will solve the last issue listed in T8923 and therefore close it.

hein added a reviewer: VDG.Sep 10 2018, 10:33 AM
hein added a subscriber: hein.

If I understood things right, prior work made sure that deactivating a client via any means (alt-tab, opening KRunner, etc.) will break a clients' pointer constraint (and hopefully recreate it when the client gets activated again). And this patch removes the previous dedicated means to do so, long-pressing ESC, and the notification informing the user of this possibility.

I'm not sure that's good. "Having" to alt-tab to break a constraint seems a bit awkward to me, like you are asked to apply a work-around to a troublesome situation.

Additionally, I think the two should kind of behave differently perhaps - alt-tab should break the constraint temporarily (until the client is activated again), ESC possibly permanently? Not sure.

I agree the notification/feature is a bit useless for fullscreen clients, though, which are naturally deactivated by quitting or alt-tabbing. I'd restrict it to windowed clients.

This is a UX thing, so the VDG should be involved.

I'm not that familiar with the intention and basis for the pointer constraint feature in the first place, so before I offer any UX opinions, can someone tell me why it exists? What's it needed for? Since it exists on Wayland but not X, is this a purely technical matter, or is there a good reason for having it but it was unimplementable in X?

I'm not that familiar with the intention and basis for the pointer constraint feature in the first place, so before I offer any UX opinions, can someone tell me why it exists? What's it needed for? Since it exists on Wayland but not X, is this a purely technical matter, or is there a good reason for having it but it was unimplementable in X?

Imagine a 3D ego-shooter like Counter Strike. When the player moves his mouse the in-game camera should spin around. What you don't want is that the compositor does not allow any more motion events to go to the client because the mouse cursor hit the screen edge.

On X clients are able to manipulate the pointer position (warp) and event delivery (grab) as they please. This is a security risk and on Wayland we have for that the secure pointer constraining protocol (lock and confine).

Any client can request such a pointer constraining and the compositor decides if it wants to allow it and for how long. Normally it will only allow it when the client has pointer focus and is active.

The question touched here is how should the user be able to unconstrain a constraining client again. It should be implicitly unconstrained when one of the conditions needed for constraining in the first place is not met anymore. For example when you hit Alt+Tab and by that the client loses pointer focus. Or when the client is killed, e.g. a full screen game through main menu going back to desktop.

But is it also necessary that the user can unconstrain the pointer explicity through some specific key combination? We do it this way until now by pressing Esc for 5 seconds.

I want to remove this functionality completely because in 99% of the cases the constraining will be gone automatically, unconstraining by pressing Esc for 5 seconds is a work-flow very uncommon to users (and most users don't even know what it means), the info message announcing it is shown annoyingly often on Xwayland and in the few cases where a rogue client is trying to harm the user or a client froze while constraining, a user can simply hit Meta or Alt+Tab to unconstrain the pointer.

Thanks Roman! I agree that changing focus with alt-tab (or anything else) should disable the pointer lock, that the notification message is annoying and should go, and that "long press esc for 5 seconds" is not very obvious and probably should go too. I find myself agreeing with @hein that pointer lock should return if the client regains focus: if I alt-tab out of my FPS game to check my email, when I alt-tab back, it should work again (provided I haven't been killed during the email break lol).

If we are trying to provide an "emergency escape valve" for poorly programmed apps that don't give up pointer locking when they should, let's consider what people do when they panic in response to an anxiety-producing situation with their computer:

  • Force-shutdown using the physical power key or power cord (not helpful)
  • Close the laptop screen (not helpful)
  • Quit the app using a keyboard shortcut, if they know one (not helpful)
  • Mash the escape key (ahh, now this is helpful!)

So instead of "long press escape for 5 seconds", how about "press the escape key in quick succession 3 or more times"?

Thanks Roman! I agree that changing focus with alt-tab (or anything else) should disable the pointer lock, that the notification message is annoying and should go, and that "long press esc for 5 seconds" is not very obvious and probably should go too. I find myself agreeing with @hein that pointer lock should return if the client regains focus: if I alt-tab out of my FPS game to check my email, when I alt-tab back, it should work again (provided I haven't been killed during the email break lol).

That's already the case.

If we are trying to provide an "emergency escape valve" for poorly programmed apps that don't give up pointer locking when they should, let's consider what people do when they panic in response to an anxiety-producing situation with their computer:

  • Force-shutdown using the physical power key or power cord (not helpful)
  • Close the laptop screen (not helpful)
  • Quit the app using a keyboard shortcut, if they know one (not helpful)
  • Mash the escape key (ahh, now this is helpful!)

    So instead of "long press escape for 5 seconds", how about "press the escape key in quick succession 3 or more times"?

There is Alt+F4 for killing misbehaving clients. Known to most people using a PC and documented in our keyboard shortcut system. In comparision hitting Escape key for several times to do something on the compositor level is not really better than long pressing. The user still would need to be informed about it somehow. We can't assume every user hits repeatedly (and fast enough) Esc when there is something not working. And what if I have to press Esc several times to quickly check a menu in game?

I find that people tend to repeatedly press Esc in "computer is scaring me" panic mode, so I don't think it would need to be documented the way "long press Esc for 5 seconds" currently needs to be. It's theoretically possible that some client would want to listen for a long-press of the Esc key as well, but we're talking about corner cases of corner cases here. :)

Since we haven't found a mutual decision on this and beta is tomorrow I want to push this change now so it can be beta-tested with the other changes I did in the last months to pointer constraining and we get some feedback from users if they miss breaking pointer constraints explicitly with Escace key. My assumption is no one will miss it, because it will work automatically or they can unconstrain misbehaving clients through other means (kill the sucker with Alt+F4 for example). If feedback says otherwise we can revert the patch.

hein accepted this revision.Sep 12 2018, 8:20 PM

Yeah, sounds good for now.

This revision is now accepted and ready to land.Sep 12 2018, 8:20 PM

OK, let's do it!

This revision was automatically updated to reflect the committed changes.