Bug 1303307 - Awesome WM: Some key bindings (e.g. window close) sporadically stop to work for already open clients
Awesome WM: Some key bindings (e.g. window close) sporadically stop to work f...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: awesome (Show other bugs)
23
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Thomas Moschny
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-30 09:33 EST by Martin Ueding
Modified: 2016-02-10 18:19 EST (History)
2 users (show)

See Also:
Fixed In Version: awesome-3.5.8-1.fc23 awesome-3.5.8-1.fc22
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-04 18:23:04 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Martin Ueding 2016-01-30 09:33:00 EST
Description of problem:

    I use Awesome WM as my windows manager. My configuration file (`rc.lua`)
    has been working just fine with a couple of tweaks. Since about yesterday
    the command for closing windows (killing clients) does not work in same
    cases. Usually this functionality is mapped to [Mod4]+[Shift]+[C], I have
    mapped it to [Mod4]+[C] in my configuration.

    So I would want to close some Konsole (KDE terminal) window and the text
    cursor there would just blink but the windows is not closed. This blinking
    suggests that the window looses focus for the duration of that keypress so
    I assume that Awesome WM still catches that key. Keybindings that move the
    window still work.

    The strange thing is that this does not apply to new clients. When I open a
    new Konsole window, I can close it just fine. All windows that were already
    open when this bug happened cannot be closed as well.

    Another thing that does not work any more is making a window the main
    window with [Mod4]+[Control]+[Space].

    From that I would guess that *some* functions that are bound to each window
    get unmapped for some reason at some point.

    The way I currently deal with the issue is a plain restart of Awesome WM
    using [Mod4]+[Shift]+[R]. This takes less than a second and is a manageable
    workaround. However I would prefer for this to be resolved.

    I suspect that this was caused by an update to Awesome WM on Fri Jan 29
    09:56:28 2016. I have automatic updates enabled (`dnf-automatic`) and this
    is the transaction I get with `dnf history info awesome`. 

    Judging from the [package website][1] I guess that there was indeed an
    update that introduced this glitch.

    [1]: https://apps.fedoraproject.org/packages/awesome/

Version-Release number of selected component (if applicable):

    3.5.7

How reproducible:

    It happens at undefined time intervals, but it has happened every now and
    then and it is annoying.

Steps to Reproduce:
1. Open a couple windows
2. Work for a while
3. Note that closing a window does not work. Also note that making a window the
   main window does not work either.

Actual results:

    Windows that were open before the glitch cannot be closed or made the main
    window.

Expected results:

    Keybindings should do their job.

Additional info:

    There has been a similar behavior in Awesome WM for a longer time which
    broke mouse bindings. So for some reason I could still perform all the
    commands with they keyboard but clicking on tags in the wibox did not have
    any effect. This must have been introduced in an earlier update but might
    be related as it (1) also occurs after some time of using the session and
    (2) is about the binding of functions to input events.

    The second screen on my display is rotated quite often, but I have not
    found that this rotation using `xrandr` has a strong correlation. Another
    soft correlation seems to be with suspend-to-ram. In both cases the window
    manager has to adjust to the new layout of the screens.
Comment 1 Martin Ueding 2016-01-30 11:50:16 EST
This problem also affects moving clients to the other screen with [Mod4]+[O].

The mouse problem is not cured by restarting Awesome WM, so this cannot directly be the same cause, I think.
Comment 2 Fedora Update System 2016-02-01 13:02:41 EST
awesome-3.5.8-1.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c5c4b725bf
Comment 3 Fedora Update System 2016-02-01 13:02:41 EST
awesome-3.5.8-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-6e58ca0128
Comment 4 Fedora Update System 2016-02-01 13:02:43 EST
awesome-3.5.8-1.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c5c4b725bf
Comment 5 Fedora Update System 2016-02-01 13:02:45 EST
awesome-3.5.8-1.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c5c4b725bf
Comment 6 Thomas Moschny 2016-02-01 14:29:00 EST
(In reply to Martin Ueding from comment #1)
> This problem also affects moving clients to the other screen with [Mod4]+[O].
> 
> The mouse problem is not cured by restarting Awesome WM, so this cannot
> directly be the same cause, I think.

According to upstream, this is a different issue, see
  https://github.com/awesomeWM/awesome/issues/635
  https://github.com/awesomeWM/awesome/issues/415
and
  https://bugreports.qt.io/browse/QTBUG-49952

If I read the Qt issue correctly, a fix will be in Qt 5.6.0.

A workaround is to set QT_XCB_NO_XI2_MOUSE=1.
Comment 7 Fedora Update System 2016-02-01 21:25:52 EST
awesome-3.5.8-1.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-c5c4b725bf
Comment 8 Fedora Update System 2016-02-01 21:26:43 EST
awesome-3.5.8-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-6e58ca0128
Comment 9 Fedora Update System 2016-02-04 18:23:02 EST
awesome-3.5.8-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Comment 10 Fedora Update System 2016-02-10 18:19:13 EST
awesome-3.5.8-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.