PassFirstClickToClient set to false prevents toolbar to handle left click

[JanD1234]

Hello.

I have observed a buggy behavior of the icewm in regards to the PassFirstClickToClient configuration option. I started to experiment with this option, because icewm randomly sends some control characters to my xterms (visible as escape characters on command line), when I'm switching focus. With PassFirstClickToClient option set to False, it looks that this behavior is limited or solved. But I have found another bug with PassFirstClickToClient. When I set it to zero, the toolbar starts to ignore left mouse click. You cannot left click to anything on the toolbar (no menu, no quick launch apps, no workspaces, no running apps, no widgets). The right and middle clicks still work, also hovering with mouse over icons shows tool tip and mouse wheel selection works. Only the left mouse button is ignored.

Bug: PassFirstClickToClient set to false prevents toolbar to handle left click

Expected behavior: PassFirstClickToClient should not influence toolbar reaction on the left mouse click.

How to reproduce: Set PassFirstClickToClient to 0 via the preference file or via "Settings -> Preferences -> M... - Z... -> PassFirstClickToClient"

OS: openSUSE Leap 15.4

Icewm version: Name : icewm Version : 3.4.5 Release : lp154.192.1 Architecture: x86_64 Build Date : Mon 08 Jan 2024 01:34:23 PM CET Packager : https://www.suse.com/ Vendor : obs://build.opensuse.org/X11

~/.icewm/preferences file: ManualPlacement=1 UseMouseWheel=1 Win95Keys = 0 ModSuperIsCtrlAlt = 0 ClickToFocus = 0 FocusOnAppRaise = 1 RequestFocusOnAppRaise = 1 RaiseOnFocus = 1 RaiseOnClickClient = 1 PassFirstClickToClient = 0 # 0/1 FocusChangesWorkspace = 1 FocusOnMap = 1 FocusOnMapTransient = 1 FocusOnMapTransientActive = 1 MapInactiveOnTop = 1 PointerFocusDelay = 500 AutoRaiseDelay = 400

TaskBarAutoHide = 0 TaskBarShowMailboxStatus = 0 TimeFormat = "%a %d %b %R" TaskBarShowCPUStatus = 0 TaskBarShowNetStatus = 0 TaskBarShowMEMStatus = 0

[gijsbers]

Thanks for reporting this! It was unclear to me why someone would ever set PassFirstClickToClient to false. If you could make a screencast of the erratic xterm behavior, that may be helpful. Only of the small screen area where the problem occurs.

PassFirstClickToClient=0 could only be desirable for application windows and not for icewm windows like the taskbar. Hence this commit should fix this bug.

It may be justified to make this a winoption. Then you can set it per application.

[JanD1234]

Hello Gijsbers.

Thank you for the patch, I will test it and let you know.

Regarding to xterm behavior, I have captured 2 snapshots. If I use only pure xterm, in case that unexpected sequence is received, xterm only beeps. If I want to visualize it somehow, I must run the Midnight commander inside of xterm. In attached pictures, you can see what is shown on the command line.

Jan

[gijsbers]

Maybe you can set the xterm allowMouseOps to false? Also check out xterm's disallowedMouseOps.

[JanD1234]

If you disable MouseOps in xterm, you cannot use mouse in any ncurses application like the Midnight commander. BTW, I switched to icewm from fvwm2 only recently and use fvwm on other my computers until I get used to icewm. I never saw such issue before the switch or on computers where I still use fvwm2. So I believe that it is not caused by xterm. I will test PassFirstClickToClient=0 and let you know if it addresses also this issue.

[gijsbers]

Your statement icewm randomly sends some control characters to my xterms is wrong. Icewm can't do that, even if it wanted to. It is now clear from your description that xterm converts a mouse click to an escape sequence.

Then the question becomes why you click. Maybe because of your ManualPlacement setting? Or because you want to focus the xterm? If you have ClickToFocus false then just moving the mouse pointer over the window should suffice. Otherwise you can click on the taskbar.

[JanD1234]

Hello.

Right, this is good point. I'm not sure now, if I need to click on window to see these characters or not. I will verify this.

The question is, in case of click, why in some cases it is translated to these characters and not in others? And why this behavior was not visible in fvwm? Normally I can click on xterm as many times as I want and no beeps or no characters are displayed. Only in same random cases, which I'm not able to reproduce on demand, it happens. Maybe it has relation to virtual desktop switching, maybe not. I can not find a system in this behavior.

[JanD1234]

By the way, when you opened ClickToFocus topic, I observe some strange behavior connected to virtual desktop switching. I use keyboard to quickly switch between my desktops, combination of Ctrl+Alt+[left arrow, right arrow, down arrow, 1, 2, 3, 4]. In case, that after desktop switch the mouse cursor ends up on the window which is not in focus, the focus does not change. I have to move mouse to other window and then back to activate focus or click on the window.

[JanD1234]

Hello.

After some more testing I can confirm that I do not need to click to xterm to see strange characters. But I must to start typing. So the scenario is, that I just move mouse to the window and because I have focus following mouse, the window become active. Then when I start typing, the first character generate bell and all next characters are normally displayed.

[gijsbers]

It is unclear where the bug originates. Does it matter if you use a different terminal? Can you visualize the input using od or hexdump? Can you reproduce it using the default settings of icewm?

I still can't reproduce the problem. Do you have special xterm resources set which may affect this behavior?

[JanD1234]

Hello.

Finally I found some time to apply your patch and recompile icewm. I can confirm, that your patch fixed the issue with toolbar I originally reported. Thank you very much.

Now I'm running icewm with PassFirstClickToClient set to false. So far, I have not observed any strange characters sent to xterm, but it's too early to draw any conclusions.

Regarding to your latest post. The biggest problem with these strange characters is that I do not see any system in when they appear. And thus, I'm not able to reproduce it on demand. I can only use icewm (which I like more and more as I'm getting more experiences with it) and wait if it happens. I run 'od' if one of my terminal and sporadically switching focus to it to see if issue appears and I can provide you more data. But as I said, nothing occurred after switching the FirstClick off. Version:

xterm -version XTerm(330)

mc -V GNU Midnight Commander 4.8.27 Built with GLib 2.70.4 Built with S-Lang 2.3.1a with terminfo database With builtin Editor With subshell support as default With support for background operations With mouse support on xterm and Linux console With support for X11 events With internationalization support With multiple codepages support With ext2fs attributes support Virtual File Systems: cpiofs, tarfs, sfs, extfs, ftpfs, sftpfs, smbfs Data types: char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64;

And the last thing I can report now, and I'm not sure if this is pertinent to this issue is, that I'm using very often keyboard for switching virtual desktops. I'm using arrow and also numbers with combination with Ctrl+Alt. Most of the time it works as expected, but sometimes it happens, that numbers stop to work. I can still use arrows. If it happen, I have to restart icewm via menu. Last time it happened, I run xev to capture keyboard.

xev output when everything works fine: KeyPress event, serial 35, synthetic NO, window 0x4a00001, root 0x248, subw 0x4a00002, time 1519832067, (38,40), root:(42,454), state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False

KeyPress event, serial 38, synthetic NO, window 0x4a00001, root 0x248, subw 0x4a00002, time 1519832076, (38,40), root:(42,454), state 0x4, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False

FocusOut event, serial 38, synthetic NO, window 0x4a00001, mode NotifyGrab, detail NotifyAncestor

You can see, that I pressed Ctrl and Alt and then number was not reported because it was captured by icewm and virtual desktop was switched.

xev output when numbers do not work: KeyPress event, serial 38, synthetic NO, window 0x4000001, root 0x248, subw 0x0, time 1513400107, (-1070,818), root:(668,858), state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False

KeyPress event, serial 38, synthetic NO, window 0x4000001, root 0x248, subw 0x0, time 1513400116, (-1070,818), root:(668,858), state 0x4, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False

KeyPress event, serial 38, synthetic NO, window 0x4000001, root 0x248, subw 0x0, time 1513400674, (-1070,818), root:(668,858), state 0xc, keycode 11 (keysym 0x32, 2), same_screen YES, XLookupString gives 1 bytes: (00) "" XmbLookupString gives 1 bytes: (00) "" XFilterEvent returns: False

KeyRelease event, serial 38, synthetic NO, window 0x4000001, root 0x248, subw 0x0, time 1513400778, (-1070,818), root:(668,858), state 0xc, keycode 11 (keysym 0x32, 2), same_screen YES, XLookupString gives 1 bytes: (00) "" XFilterEvent returns: False

KeyRelease event, serial 38, synthetic NO, window 0x4000001, root 0x248, subw 0x0, time 1513401526, (-1070,818), root:(668,858), state 0xc, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False

KeyRelease event, serial 38, synthetic NO, window 0x4000001, root 0x248, subw 0x0, time 1513401528, (-1070,818), root:(668,858), state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False

You can see, that after pressing Ctrl + Alt, also number 2 was sent to xev and then all keys were released. icewm did not recognize this special combination of keys. After icewm was restarted, it begins to work again. In reality, the first working log was captured after issue occurred and I restarted icewm.

[JanD1234]

Update to the issue described above. After I sent the comment I tried one more test. I switched keyboard from English to my national keyboard then back. My national keyboard redefines numbers - 1 is +, 2 is ľ and so on. And numbers stopped to work for desktops switching regardless that I switched keyboard back to English. In other applications, I can see that numbers generating numbers again.

od command produced following output for Ctrl+Alt+1,2,3,4:

od ^[1^[^@^[^[^\Quit (core dumped)

I'm using Ibus 1.5.25 for keyboard switching.

[gijsbers]

The patch which fixes this bug was included in version 3.4.6, which was released one week ago.

You can define additional keys for switching virtual desktops in the keys file using icesh.

[JanD1234]

Hello.

Thank you for the tip. I downloaded, compiled and installed version 3.4.6. I realized that the patch for the PassFirstClickToClient is already included.

But, it does not solve the above described issue with virtual desktop switching after keyboard is switched to national language and back.

Result of keys 1, 2, 3 and 4 without any modifiers:

od 1234

Result with national keyboard:

od +ľšč

Result with no modifiers after switching back to english keyboard:

od 1234

Result with Ctrl+Alt with english keyboard after switched from national keyboard:

od ^[1^[^@^[^[^\Quit (core dumped) Desktops are not switched.

Expected result: Virtual desktop are switched.

[gijsbers]

That is unfortunate. For a Slovak keyboard layout you can define the following preferences:

#  Goes to workspace 2.
KeySysWorkspace2="Ctrl+Alt+lcaron"

#  Goes to workspace 3.
KeySysWorkspace3="Ctrl+Alt+scaron"

#  Goes to workspace 4.
KeySysWorkspace4="Ctrl+Alt+ccaron"

I believe this should also work when you switch to a US keyboard layout.

[JanD1234]

Ok, I will try. But do you know the root cause, why icewm is not able to recover, after the keyboard is switched back? It must be restarted and it works again until keyboard is switched.

[gijsbers]

This commit adds support for specifying various international characters and non-standard characters in keybindings like so:

#  Goes to workspace 2.
KeySysWorkspace2="Ctrl+Alt+ľ"

#  Goes to workspace 3.
KeySysWorkspace3="Ctrl+Alt+š"

#  Goes to workspace 4.
KeySysWorkspace4="Ctrl+Alt+č"

It also reparses all keyboard bindings whenever the keyboard layout changes.

[JanD1234]

Hello.

I have a few new comments.

1. PassFirstClickToClient set to false does not solve the issue with strange characters.
2. You do not need to click to xterm to see strange characters. Only start typing.
3. I can confirm, that your commit from the previous message solves issue switching virtual desktops with numbers.
4. Maybe I found a way how to reproduce strange characters behavior:
   • In the xterm, run the 'od' command.
   • Click simultaneously Ctrl+Alt. In some cases the od does not show anything, but in some cases it shows following:

     od ^[^[^[^[ each '^[' is one Ctrl+Alt click

   • If you cannot reproduce it, try switch desktops using keyboard and try again. Repeat Ctrl+Alt multiple times in xterm with "od".
   • If '^[' is in buffer, typing standard characters generates the strange character or better to say - escape sequence, which translates to beep into xterm.
   • It looks, that Ctrl+Alt is not always processed correctly.

[gijsbers]

It is unclear where the bug originates. Does it matter if you use a different terminal?

I still can't reproduce the problem.

It could very well be a bug in xterm. Then you better talk to xterm developers.

[JanD1234]

Hello. For your information, I tried rxvt-unicode and lxterminal. None of them exhibit the same behavior as xterm. I switched to lxterminal to overcome the reported issue.