Closed boycottsystemd closed 3 years ago
icewm-1.9.0-1.fc31 (Edit does not work)
I checked the code execution path for such a button press and I can't find something questionable. Maybe the button release event got lost somewhere or it was reordered, but then it could be anywhere. X11 server or kernel or ...?
Something similar happened when I've clicked minimize icon of the PCManFM. Icon has changed its colors but window did not minimize.
icewm 2.0.0.1.fc32
I'm not sure how this journalctl output is related to this bug: Dec 23 19:19:36 fedora /usr/libexec/gdm-x-session[8388]: See https://wayland.freedesktop.org/libinput/doc/1.16.1/absolute_coordinate_ranges.html for details Dec 23 19:19:36 fedora /usr/libexec/gdm-x-session[8388]: (II) Axis 0x1 value -600 is outside expected range [-31, 651]
So it looks like the button press event was received by icewm, because the button is shown as pressed down. But then the button release event is not received, because the button remains down. The journalctl output may support this hypothesis. For the minimize to occur, both the button press and the button release must occur inside the button rectangle. Icewm can't help it that the button release is never received. That is caused by some other software layer.
I've "L"-clicked on gvim icon on the icewm toolbar but gvim has not been launched. Icon still looks like in "pressed-like" state. It has never happened before. High hard disk activity (grep on big open source project code) was present during attempt to launch gvim.
Fedora 31, kernel 5.8.16-100.fc31.x86_64
I don't know how to reproduce it.
TaskBarAutoHide=1 AutoHideDelay=3 AutoRaiseDelay=0 AutoShowDelay=0