wavexx commented 6 years ago

I discovered a case where spectrwm (latest build from master) seems to break the behavior of al wx-gtk program in a puzzling way.

Clicks with the 1st mouse button do not behave as expected with an empty spectrwm config, while they work with other WMs (awesome, i3). I tried the most obvious things (disable swmhack, quirks, focus mode), but no dice.

This is happening on slic3r-pe 1.41.1.

https://github.com/prusa3d/Slic3r/releases : get the latest tar.bz2, unpack, run directly with ./slic3r from the tarball.

Just dismiss the wizard with ESC, click "Add" on the toolbar and load something (https://www.thingiverse.com/download:1990663).

It will appear as bright green. Click immediately with the 3rd mouse button on the third icon on the side:

2018-11-06t234505

you will see it turns orange and triggers some rotation behavior.

Kill slic3r, re-run and use the 1st mouse button to do the same instead: it doesn't work. Somehow, slic3r sees some other pointer event that causes a deselection.

If you try with another wm (twm will do), it works as intended.

Is there anything that could affect the behavior of the pointer events?

LordReg commented 6 years ago

Issue is related to the mouse button1 grab used for the focus action. I also sometimes experience the issue in a few apps. Looking for a solution, but in the mean time you can workaround the issue by disabling the default bind: bind[] = ANYMOD+Button1

wavexx commented 6 years ago

On Wed, Nov 07 2018, LordReg wrote:

Issue is related to the mouse button1 grab used for the focus action. I also sometimes experience the issue in a few apps. Looking for a solution, but in the mean time you can workaround the issue by disabling the default bind: bind[] = ANYMOD+Button1

This would explain some weird behavior which I had in some other apps from time to time. However, with slic3r it really breaks the program completely (and reliably).

Could I help diagnosing this? Any pointers to where this happens in the source?

wavexx commented 6 years ago

On Wed, Nov 07 2018, LordReg wrote:

bind[] = ANYMOD+Button1

BTW, this definitely fixes/confirms the issue.

LordReg commented 6 years ago

The issue is that button1 is passively grabbed on an ancestor of the application window (root in this case). When the grab is activated by pressing button1, the pointer effectively moves to another window, causing leavenotify with a mode of ungrab to be sent to the application window. Some programs, such as slic3r, treat this as a focus change to another window. I would consider that an issue with the program. Programs should be able to handle button presses being intercepted and replayed.

After giving this some thought, a solution/workaround would be to switch to grabbing the focus button bindings on each relevant window (including bar/region input windows) instead of root. When an application becomes focused, the focus button grab(s) can be released for the window. When the window loses focus, the binding(s) can be re-grabbed.

wavexx commented 5 years ago

On Wed, Nov 07 2018, LordReg wrote:

Issue is related to the mouse button1 grab used for the focus action. I also sometimes experience the issue in a few apps. Looking for a solution, but in the mean time you can workaround the issue by disabling the default bind: bind[] = ANYMOD+Button1

I have to admit, I didn't have any time to look at this.

I ran without the default bind for a while, but well... you do notice its absence ;)

marcopeereboom commented 5 years ago

@LordReg did you produce a patch for this?

wavexx commented 5 years ago

Sadly, I realized this particular issue also breaks all those "overlay" GTK3 scrollbars which are increasingly common.

marcopeereboom commented 5 years ago

@LordReg halp!!

LordReg commented 5 years ago

@marcopeereboom on it

wavexx commented 5 years ago

Bump

marcopeereboom commented 5 years ago

@LordReg any news?

wavexx commented 4 years ago

@LordReg we know you're keeping the fix in your repo, c'mon ;)

LordReg commented 4 years ago

@wavexx true ;) there is a focus issue complication I need to resolve before it is ready.

LordReg commented 4 years ago

@wavexx fixed some input focus issues that may have solved this issue. would you please verify?

wavexx commented 4 years ago

On Wed, Jun 17 2020, LordReg wrote:

@wavexx fixed some input focus issues that may have solved this issue. would you please verify?

Last commit is very crashy. I have this happening every time gpgagent pops up:

Core was generated by `./spectrwm'. Program terminated with signal SIGSEGV, Segmentation fault.

0 0x00005555555697ec in set_focus_redirect (win=0x55555579a9b0) at ../spectrwm.c:6719

6719 tmpw->focus_redirect = w; (gdb) p tmpw $1 = (struct ws_win *) 0x0 (gdb) where

0 0x00005555555697ec in set_focus_redirect (win=0x55555579a9b0) at ../spectrwm.c:6719

1 0x000055555557499a in manage_window (id=31457283, spawn_pos=0, mapping=true)

at ../spectrwm.c:11139

2 0x0000555555576738 in maprequest (e=0x5555556c1990) at ../spectrwm.c:12258

3 0x0000555555579be9 in event_handle (evt=0x5555556c1990) at ../spectrwm.c:13538

4 0x000055555557a1c8 in main (argc=1, argv=0x7fffffffe028) at ../spectrwm.c:13723

LordReg commented 4 years ago

@wavexx fixed

wavexx commented 4 years ago

On Wed, Jun 17 2020, LordReg wrote:

@wavexx fixed

Ok, crash fixed.

But the underlying issue still seem to be a problem. Gtk3 overlay scrollbars are still broken unless I unbind ANYMOD+Button1.

Quickest way to test this is by running any gtk3 program with a text edit widget with scrollbars. The "gtk3-widget-factory" demo is what I've used to test this.

LordReg commented 4 years ago

Which version of gtk are you running? I just tried gtk3-widget-factory on gtk 3.24.20 and the scrollbars on the text edit widgets seem to work correctly for me.

wavexx commented 4 years ago

On Wed, Jun 17 2020, LordReg wrote:

Which version of gtk are you running? I just tried gtk3-widget-factory on gtk 3.24.20 and the scrollbars on the text edit widgets seem to work correctly for me.

Running on debian unstable: 3.24.20. Does the widget-factory shows proper overlay scrollbars?

Go nearby the scrollbar to that it expands, but stay away far enough so that you're outside the "thin" collapsed form. The handle will highlight, but as soon as you click on it it will disappear and select the underlying text. This immediately goes away after unbinding Button1.

I could try to record a small video if you want to see this.

LordReg commented 4 years ago

That explanation was helpful. I see no issue when I click and drag the overlay. I was able to reproduce the issue by clicking the overlay without moving the pointer. The overlay fades and disappears if ANYMOD+Button1 is bound.

wavexx commented 1 year ago

FIY the behavior regarding the overlay scrollbars in gtk3 isn't gone even with cd55588.

I can still reproduce it on the gtk3-widget-factory.

The simplest program linking with gtk-3 on my system with overlay scrollbars seems to be "pavucontrol". Just go to the config tab, shrink the window until control don't fit then you get two overlay scrollbars that still doesn't play nicely.

gucharmap also has an overlay bar in the unicode block list.

Saying this because I'm not using slic3r-pe anymore to reproduce this issue: overlay scrollbars are more annoying (in every damn sense).

Behavior of the overlay scrollbar with gucharmap, ANYMOD+Button1 unbound:

unbound2

notice how you can go to the very edge of the bar, stop, click and the handle will attach to the current position. Behavior as expected.

Now with ANYMOD+Button1 bound:

bound

the same just makes the bar disappear. The working hit zone is the width of the collapsed bar.

LordReg commented 1 year ago

You are only running cd555885? Most of the improvements come after. Current is 67e16a13 :)

cd555885 alone may not be sufficient to workaround the gtk3-widget-factory issue. I suspect GTK may have overlooked these issues since mutter ungrabs click-to-focus on focused windows.

This is where the 9a8989d0 comes in. Button bindings with the REPLAY flag (e.g. default focus binding) are handled passively, without grabs. The click passes directly to the program the same as being unbound.

wavexx commented 1 year ago

Yes, I'm building on current master (67e16a1)

wavexx commented 1 year ago

Hah, turns out I had a stale binary in my $PATH while I was testing this. Re-testing this now, again, I can't see any difference so it seems to work as intended :)

LordReg commented 1 year ago

Good! Actually, cd55588 did fix this issue. 9a8989d is better. Should have asked you to verify spectrwm -v ;)

wavexx commented 1 year ago

Your comment was enough to make me dubious. The issue here is that I sometimes used Xephyr as a test bench and ran ./spectrwm from the built path. Right now I was testing from my main config, but I was still getting the wrong binary. Sorry for the noise.

Ironically.. I was testing the xrandr reconfig issue, and for 5 times in a row I didn't have issues! Maagic :P

conformal / spectrwm

Messes with slic3r-pe mouse behavior #224

0 0x00005555555697ec in set_focus_redirect (win=0x55555579a9b0) at ../spectrwm.c:6719

0 0x00005555555697ec in set_focus_redirect (win=0x55555579a9b0) at ../spectrwm.c:6719

1 0x000055555557499a in manage_window (id=31457283, spawn_pos=0, mapping=true)

2 0x0000555555576738 in maprequest (e=0x5555556c1990) at ../spectrwm.c:12258

3 0x0000555555579be9 in event_handle (evt=0x5555556c1990) at ../spectrwm.c:13538

4 0x000055555557a1c8 in main (argc=1, argv=0x7fffffffe028) at ../spectrwm.c:13723