I am not sure if this bug are related to libxfce4ui, but since it affects the general desktop I think it's on here (if I am wrong, please move to the right section). It's simples, sometimes the desktop simple don't respond to user clicks or keyboard input. The mouse rollover still works, but you can't click or input anything with keyboard until you try to resize some window. If you don't have any window to resize, you have to restart X. How to reproduce: -The easiest way I found is using Sakura terminal. Simple open a Sakura instance and close. After you try to close (using the X button), the bug is triggered. -Have problems too when I tried to open some photos of my sdcard with Thunar. I am using Arch Linux x86 with a Aspire One D250 netbook. Didn't had this problem on x64 version (but I didn't upgrade my x64 setup to 4.8.0 release, using p3).
I guess from the description that would be xfwm4 yet I cannot reproduce the problem. Can you please attach the output of "xfconf-query -c xfwm4 -vl"? Maybe there's something with your config that would help with reproducing
Created attachment 3374 Output from xfconf-query -c xfwm4 -vl
Tried to remove configuration files and do a flesh start (since I migrate my configuration files from Xfce 4.6), without success. And deactivating composite don't work either. But I found a method to trigger the bug more easily: -Start sakura terminal. -Execute a program that didn't quit without user input (like vim, su, less <file> etc.). -Try to close sakura terminal without quiting from the program above. -sakura will show a message confirming if you want to quit and the bug is triggered. -If this didn't work at first, just close the message and try to close sakura again. When the bug occurs, anywhere I double click on the window just maximize/windowed the window, but I can't input anything on keyboard or click. The way I found to restore the user input is try to move the window. When the bug is triggered I can't really move the window either, but the user input is restored until the bug is triggered again. Hope this information is useful.
(In reply to comment #3) > But I found a method to trigger the bug more easily: > -Start sakura terminal. > -Execute a program that didn't quit without user input (like vim, su, less > <file> etc.). > -Try to close sakura terminal without quiting from the program above. > -sakura will show a message confirming if you want to quit and the bug is > triggered. Not really, it's a moda ldialog, meaning that the parent window can't receive focus until that dialog is closed. Yet I can focus any other window, and once the dialog is closed, I can focus Sakura as before. > -If this didn't work at first, just close the message and try to close sakura > again. Still cannot reproduce. > When the bug occurs, anywhere I double click on the window just > maximize/windowed the window, but I can't input anything on keyboard or click. > The way I found to restore the user input is try to move the window. When the > bug is triggered I can't really move the window either, but the user input is > restored until the bug is triggered again. What if you switch to another workspace back and forth, does it release the focus?
(In reply to comment #4) > (In reply to comment #3) > > But I found a method to trigger the bug more easily: > > -Start sakura terminal. > > -Execute a program that didn't quit without user input (like vim, su, less > > <file> etc.). > > -Try to close sakura terminal without quiting from the program above. > > -sakura will show a message confirming if you want to quit and the bug is > > triggered. > > Not really, it's a moda ldialog, meaning that the parent window can't receive > focus until that dialog is closed. Yeah, I know, but I was refering to other windows than sakura. > > Yet I can focus any other window, and once the dialog is closed, I can focus > Sakura as before. > > > -If this didn't work at first, just close the message and try to close sakura > > again. > > Still cannot reproduce. Strange, maybe it's a downstream (Arch) or something with my configuration. It's is easy to trigger if you try to close with Alt+F4 instead clicking on X button. > > > When the bug occurs, anywhere I double click on the window just > > maximize/windowed the window, but I can't input anything on keyboard or click. > > The way I found to restore the user input is try to move the window. When the > > bug is triggered I can't really move the window either, but the user input is > > restored until the bug is triggered again. > > What if you switch to another workspace back and forth, does it release the > focus? No, since I can't change the workspace (by clicking or using mousewheel, even keyboard shortcuts don't work).
Do you run some particular program that I may not be running? Do you use scim? I might be missing something... to reproduce. Could you please post the output of xlsclients? I would really like to reproduce otherwise it'll be hard to fix...
Created attachment 3379 pacman -Q output (all installed packages) What is Scim? Since I don't know, I upload my package output
Created attachment 3380 xlsclients output
Humm, installed Arch Linux x86 (32bits) with xfce 4.8 and sakura and I still cannot reproduce.
(In reply to comment #9) > Humm, installed Arch Linux x86 (32bits) with xfce 4.8 and sakura and I still > cannot reproduce. Are you testing on a notebook/netbook/anything that uses a touchpad (using xf86-input-synaptic)? I am using a mouse for sometime now, and the bug didn't happen since. Considering that on my desktop (that uses a mouse) this bug didn't occur too, maybe there is some connection.
(In reply to comment #3) > When the bug occurs, anywhere I double click on the window just > maximize/windowed the window, but I can't input anything on keyboard or click. > The way I found to restore the user input is try to move the window. When the > bug is triggered I can't really move the window either, but the user input is > restored until the bug is triggered again. > > Hope this information is useful. Sounds like if Alt what kept pressed (ie Alt + double click anywhere would maximize and restore the window). Do you have any way to downgrade xfwm4 (just xfwm4) to 4.6.2 on that exact same system and try? I would like to determine if this is really related to a possible regression in xfwm4 or if it is something else.
Complete shoot in the dark, can you try with git head as well, after commit ef6e13761
(In reply to comment #12) > Complete shoot in the dark, can you try with git head as well, after commit > ef6e13761 Great, seems like it worked.
Fixed in xfwm4 4.8.1