New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

i3 stops responding to keyboard input when certain windows close #3096

Closed
ashkitten opened this Issue Dec 20, 2017 · 12 comments

Comments

Projects
None yet
6 participants
@ashkitten

ashkitten commented Dec 20, 2017

Output of i3 --moreversion 2>&- || i3 --version:

Binary i3 version:  4.14.1-227-g13ca7830 (2017-12-12, branch "gaps-next") © 2009 Michael Stapelberg and contributors
Running i3 version: 4.14.1-227-g13ca7830 (2017-12-12, branch "gaps-next") (pid 1580)
Loaded i3 config: /home/ash/.config/i3/config (Last modified: Wed 20 Dec 2017 08:09:32 AM EST, 2481 seconds ago)

The i3 binary you just called: /usr/bin/i3
The i3 binary you are running: i3

URL to a logfile as per https://i3wm.org/docs/debugging.html:

https://ptpb.pw/C9X4

What I did:

I closed Steam on a workspace by itself

What I saw:

i3 stopped responding to keyboard input entirely

What I expected instead:

i3 should continue to respond to keyboard input normally

Extra info:

This occurs inconsistently - mainly when a window is on a workspace by itself, but only with certain windows. This happens with Steam as well as with my project yotredash.

@i3bot

This comment has been minimized.

Show comment
Hide comment
@i3bot

i3bot Dec 20, 2017

I don’t see a link to logs.i3wm.org. Did you follow https://i3wm.org/docs/debugging.html? (In case you actually provided a link to a logfile, please ignore me.)

i3bot commented Dec 20, 2017

I don’t see a link to logs.i3wm.org. Did you follow https://i3wm.org/docs/debugging.html? (In case you actually provided a link to a logfile, please ignore me.)

@ashkitten

This comment has been minimized.

Show comment
Hide comment
@ashkitten

ashkitten Dec 20, 2017

The log file is an excerpt, including just the logs between when I closed the window and when I switched to a different workspace to fix the keyboard.

ashkitten commented Dec 20, 2017

The log file is an excerpt, including just the logs between when I closed the window and when I switched to a different workspace to fix the keyboard.

@Airblader Airblader added the bug label Dec 20, 2017

@Airblader

This comment has been minimized.

Show comment
Hide comment
@Airblader

Airblader Dec 20, 2017

Member

I assume this is the same problem as with TK (#2722). Does your application use SetInputFocus to acquire focus?

Member

Airblader commented Dec 20, 2017

I assume this is the same problem as with TK (#2722). Does your application use SetInputFocus to acquire focus?

@ashkitten

This comment has been minimized.

Show comment
Hide comment
@ashkitten

ashkitten Dec 20, 2017

Not sure. It's using glutin/winit to create the window, but alacritty also uses that and doesn't have the issue so ¯(°_o)/¯

ashkitten commented Dec 20, 2017

Not sure. It's using glutin/winit to create the window, but alacritty also uses that and doesn't have the issue so ¯(°_o)/¯

@Airblader

This comment has been minimized.

Show comment
Hide comment
@Airblader

Airblader Dec 20, 2017

Member

What does yotredash do? How can I run it? Steam isn't a reason to keep this ticket open as we do not support closed-source software, so we'll need some open-source software to reproduce the problem.

Also, can you try running the patch I posted in #2722 to see whether Steam / yotredash work as expected with that patch applied?

Member

Airblader commented Dec 20, 2017

What does yotredash do? How can I run it? Steam isn't a reason to keep this ticket open as we do not support closed-source software, so we'll need some open-source software to reproduce the problem.

Also, can you try running the patch I posted in #2722 to see whether Steam / yotredash work as expected with that patch applied?

@orestisf1993

This comment has been minimized.

Show comment
Hide comment
@orestisf1993

orestisf1993 Dec 20, 2017

Member

Your patch does work for Steam for me.

Member

orestisf1993 commented Dec 20, 2017

Your patch does work for Steam for me.

@Airblader

This comment has been minimized.

Show comment
Hide comment
@Airblader

Airblader Dec 20, 2017

Member

Great. How about someone(TM) runs the patch for a few days to see if there's any side effects and if there isn't, we just go ahead and merge it?

Member

Airblader commented Dec 20, 2017

Great. How about someone(TM) runs the patch for a few days to see if there's any side effects and if there isn't, we just go ahead and merge it?

Airblader added a commit to Airblader/i3-original that referenced this issue Dec 20, 2017

Refocus focused window for FOCUS_IN events on the root window.
This deals with (admittedly somewhat misbehaving) clients which
use XSetInputFocus to take focus, but then don't properly restore
focus. This has been observed with TK apps, but also, e.g., Steam.

fixes i3#2722
fixes i3#3096
@ashkitten

This comment has been minimized.

Show comment
Hide comment
@ashkitten

ashkitten Dec 20, 2017

The patch seems to work for Steam and yotredash.

As for your inquiry about what yotredash is and how to run it - it's my project to create a shader demotool comparable to https://shadertoy.com, and it's pretty easy to run with rust nightly and cargo, just like any other Rust application.

ashkitten commented Dec 20, 2017

The patch seems to work for Steam and yotredash.

As for your inquiry about what yotredash is and how to run it - it's my project to create a shader demotool comparable to https://shadertoy.com, and it's pretty easy to run with rust nightly and cargo, just like any other Rust application.

@tivervac

This comment has been minimized.

Show comment
Hide comment
@tivervac

tivervac Mar 5, 2018

@Airblader there hasn't been any new response for a while but the patch appears to be working for the reporter, can this issue be closed?

tivervac commented Mar 5, 2018

@Airblader there hasn't been any new response for a while but the patch appears to be working for the reporter, can this issue be closed?

@Airblader

This comment has been minimized.

Show comment
Hide comment
@Airblader

Airblader Mar 5, 2018

Member

@tivervac I've pinged Michael on the PR to discuss how we move forward.

Member

Airblader commented Mar 5, 2018

@tivervac I've pinged Michael on the PR to discuss how we move forward.

stapelberg added a commit that referenced this issue Mar 10, 2018

Refocus focused window for FOCUS_IN events on the root window. (#3097)
This deals with (admittedly somewhat misbehaving) clients which
use XSetInputFocus to take focus, but then don't properly restore
focus. This has been observed with TK apps, but also, e.g., Steam.

fixes #2722
fixes #3096
@psychon

This comment has been minimized.

Show comment
Hide comment
@psychon

psychon Aug 17, 2018

Since I have seen some people here and in #3096, #2722, #2600 ("We closed it because the application ignored the specifications and violently stole focus from the window manager's control") claim that clients that call XSetInputFocus violate "the specification", I felt like I should quote ICCCM § 4.1.7:

Clients that use a SetInputFocus request must set the time field to the timestamp of the event that caused them to make the attempt. [...] Note that clients must not use CurrentTime in the time field.

(You really should read the full section, this part should just highlight that SetInputFocus requests are fine; in reality there are four different focus modes and in just two of them, the WM is fully in control (and one of them is "I never want the focus")).

(Oh and ICCCM also explicitly requires RevertToParent for SetInputFocus, so with a non-reparenting WM, that means that the root window gets focused afterwards while for a reparenting WM, the WM's container window gets focused and then... I guess nothing gets the focus when the WM destroys its container window)

And since you claim that _NET_ACTIVE_WINDOW messages are the way to go, EWMH says:

If a Client wants to activate another window, it MUST send a _NET_ACTIVE_WINDOW client message to the root window:

So this does not change anything about self-activation and does not invalidate two of the focus modes from ICCCM.

(And from experience, I can tell you that anything involving WM_TAKE_FOCUS is a pain)

psychon commented Aug 17, 2018

Since I have seen some people here and in #3096, #2722, #2600 ("We closed it because the application ignored the specifications and violently stole focus from the window manager's control") claim that clients that call XSetInputFocus violate "the specification", I felt like I should quote ICCCM § 4.1.7:

Clients that use a SetInputFocus request must set the time field to the timestamp of the event that caused them to make the attempt. [...] Note that clients must not use CurrentTime in the time field.

(You really should read the full section, this part should just highlight that SetInputFocus requests are fine; in reality there are four different focus modes and in just two of them, the WM is fully in control (and one of them is "I never want the focus")).

(Oh and ICCCM also explicitly requires RevertToParent for SetInputFocus, so with a non-reparenting WM, that means that the root window gets focused afterwards while for a reparenting WM, the WM's container window gets focused and then... I guess nothing gets the focus when the WM destroys its container window)

And since you claim that _NET_ACTIVE_WINDOW messages are the way to go, EWMH says:

If a Client wants to activate another window, it MUST send a _NET_ACTIVE_WINDOW client message to the root window:

So this does not change anything about self-activation and does not invalidate two of the focus modes from ICCCM.

(And from experience, I can tell you that anything involving WM_TAKE_FOCUS is a pain)

@Airblader

This comment has been minimized.

Show comment
Hide comment
@Airblader

Airblader Aug 17, 2018

Member

@psychon Thanks for clarifying, I seem to indeed have been mistaken there.

(And from experience, I can tell you that anything involving WM_TAKE_FOCUS is a pain)

s/WM_TAKE_FOCUS/X11/

Member

Airblader commented Aug 17, 2018

@psychon Thanks for clarifying, I seem to indeed have been mistaken there.

(And from experience, I can tell you that anything involving WM_TAKE_FOCUS is a pain)

s/WM_TAKE_FOCUS/X11/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment