[SOLVED] Browsers cannot click some small HTML elements

allencch · 2023-12-26 13:11:55

I have an issue with Brave for quite some time, when clicking the HTML elements, such as WhatsApp Web the small caret on the right hand, it cannot be clicked. Keep disappearing whenever I click.
Recently, I have changed to Firefox which also has the same issue.

On Firefox, I cannot click the Slack message's small buttons on the right-hand of the message.

I am using `icewm` and `picom`.

I tried to disable all the extensions or add-ons, but the issue remains.

Does anyone else experience this?

Last edited by allencch (2023-12-27 05:00:31)

Head_on_a_Stick · 2023-12-26 13:43:36

Do they work if you kill the compositor?

seth · 2023-12-26 19:46:47

when clicking the HTML elements

on what url?

Keep disappearing whenever I click.

sounds like somebody's currently learning javascript, notably since you seem to have the same problem across multiple browsers.

allencch · 2023-12-27 04:59:42

Head_on_a_Stick wrote:

Do they work if you kill the compositor?

Even killing `picom` also not work. I believe it is related to `icewm`.

Last edited by allencch (2023-12-27 05:02:52)

allencch · 2023-12-27 05:00:17

seth wrote:

when clicking the HTML elements
on what url?
Keep disappearing whenever I click.
sounds like somebody's currently learning javascript, notably since you seem to have the same problem across multiple browsers.

WhatsApp Web and Slack.

allencch · 2023-12-27 05:02:23

I found a reliable solution, though it doesn't fix the unknown root cause.

1. Before clicking the HTML element, such as the small caret, I do Alt + Mouse Left Click, this will make the mouse cursor as moving the window.
2. Release the Alt key
3. Now can click the HTML element as usual.

seth · 2023-12-27 07:57:01

I believe it is related to `icewm`.

Did you test the behavior in eg. an openbox session?

WhatsApp Web and Slack.

That's not urls…

allencch · 2023-12-27 09:15:44

seth wrote:

Did you test the behavior in eg. an openbox session?

Not tested on Openbox, but no issue when I was using Openbox quite some time ago.

seth wrote:

That's not urls…

Eg URL https://web.whatsapp.com

seth · 2023-12-27 14:19:13

no issue when I was using Openbox quite some time ago

I'd maybe test openbox quite now…
And in doubt rather to "export GDK_CORE_DEVICE_EVENTS=1"

https://web.whatsapp.com/ just shows me an image of localized text telling me that it'll work w/ chrome 60+ and I shall upgrade.
I'm not using a chrome/ium based browser.
Clearly geniuses at work at meta farcebook.

Trilby · 2023-12-27 15:44:01

It's worse than that - I get the same "error" even though I am using chrome/ium based browser (w/ chrome/ium version 112 ... which I'm pretty sure is higher than 60). There really is no world wide web anymore, there is the google chrome (sensu stricto) web, and everyone else.

allencch · 2023-12-28 05:32:13

I can confirm it is related to `icewm`.

There is some discussions on GitHub. https://github.com/ice-wm/icewm/issues/62

seth · 2023-12-28 07:03:32

Did you confirm the "on top" or window sized condition and that the behavior is indeed exclusive to icewm and does not affect eg. openbox *right now*?
Did you try to "export GDK_CORE_DEVICE_EVENTS=1"?

Also the OnTop workaround might lose its effectiveness if one switch out to another window and then back.

This is all a bit very much non-deterministic

A possible explanation might be some weird interference between
1. the javascript handler/implementation
2. gtk
3. chrome window handling
4. https://tronche.com/gui/x/xlib/input/XGrabButton.html resp. https://tronche.com/gui/x/xlib/input/XAllowEvents.html or possibly https://tronche.com/gui/x/xlib/window/XRaiseWindow.html / https://tronche.com/gui/x/xlib/window/X … ndows.html

GTK is known to be broken vey much mutter/metacity behavior-specifically implemented wrt the latter, this can be mitigated w/ the core events but:
1. typically affected (only) wheel events (because basically every WM intercepts lmb clicks)
2. affected almost every WM that wasn't mutter/metacity one way or another
3. I really don't see how the layer could be relevant (rather the Substructure notification)
4. the suggested relevant window size (and website specificness) suggests this is more a javascript that GTK issue (attempting to handle an event and fucking up)

allencch · 2023-12-28 08:42:59

I tested OnTop solution, and it works.

I tried also "export GDK_CORE_DEVICE_EVENTS=1", but this didn't work.

seth · 2023-12-28 13:24:24

Does the OnTop "solution" depend on whether multiple clients are on top of the stack?
Could you reproduce the testcase in the bug (cause unlike META, that actually appears in my browsers, incl. chromium - where whatsapp told me that I need to manage cookies, showed me a list of how to block cookies in various browsers and a button to confirm cookies with a warning that whatsapp won't work if I block them in … FU ZUCKERZWERG.

allencch · 2023-12-28 16:00:59

If there are 2 windows both are OnTop, then on top solution doesn't work. Alt+Left Mouse Button click works better.

To reproduce the bug,

1. Use icewm and run a web browser like Firefox
2. Visit https://openinframap.org/, mouseover right-hand Layers icon
3. It should expand a list of layers that can be checked.
4. Click the checkbox, then the checkbox is not able to be clicked and the menu is collapsed.

To solve this,

5. Alt + LMB (left mouse button), now it can move the window (browser), doesn't need to move, just do a click is sufficient.
6. Release the Alt key, now can click the checkbox.

To reproduce the bug again,

7. Press Alt + Tab to switch to another window, and switch back.
8. Click the checkbox, not able to click.

seth · 2023-12-28 16:57:58

Does

xev -root -event substructure | grep Configure

generate any events when you're clicking into a window that's already on top of the stack and is not the only one in its layer?

allencch · 2023-12-28 17:09:26

Tried the above command by opening a terminal and a browser side by side.

Click the checkbox in the https://openinframap.org/, if it fails to click, then it generates one event of line, as

ConfigureNotify event, serial 18, synthetic NO, window 0x1c7,

If I can click the checkbox successfully, there is no event generated.

seth · 2023-12-28 20:01:07

I assume you cannot replicate this w/ openbox at all (there's a chance that this is a conditional popup window, but I doubt it)
To be absolutely sure, also run

xev -event focus -event mouse -id $(xwininfo -wm | awk '/Window id:/{print $4}')

click the browser window (that picks up the WId for xev) and see whether the click generates focus or leave events.

If you want to comment on the upstream bug, the issue is most likely that IceWM unconditionally calls XRestackWindows (even if there's no need b/c the window is on top of the stack) and that somehow "irritates" chromium.

I'd argue that both have a bug here - one's inefficient and the other one petty.

allencch · 2023-12-29 02:19:51

I tried to use the above command, but it is hard to test. Basically, this is the result

1. On the page https://openinframap.org , when I click the layer icon, there is no event shown, but the layer menu is expanded
2. Try to click the checkbox, it fails to check the box, but xev shows this

LeaveNotify event, serial 18, synthetic NO, window 0xa0003e,
    root 0x1c7, subw 0xa00052, time 2144733, (2367,435), root:(2367,435),
    mode NotifyGrab, detail NotifyVirtual, same_screen YES,
    focus NO, state 256

FocusIn event, serial 18, synthetic NO, window 0xa0003e,
    mode NotifyNormal, detail NotifyNonlinear

EnterNotify event, serial 18, synthetic NO, window 0xa0003e,
    root 0x1c7, subw 0xa00052, time 2144735, (2367,435), root:(2367,435),
    mode NotifyUngrab, detail NotifyVirtual, same_screen YES,
    focus YES, state 256

seth · 2023-12-29 07:51:45

I get that sequence on a different browser and WM and it also gets me a single substructure event on the root window when clicking that (in a non-blink browser) but for the first time one, so chances are this particular action actually causes some legitimate event (like a single pixel appearing under the mouse) there. Does the checkbox work on subsequent attempts?

allencch · 2023-12-29 13:41:24

When running xev, first attempt fails to click the checkbox, but the subsequent attempts are successful.

I have made a bug report on icewm official GitHub. The contributor replied that version 3.4.5 fixes this issue.

One of the commit shows this

Strange Firefox Behavior in IceWM. Icewm retains
a button grab after focusing. This is problematic for Firefox and Chrome
with hover elements on webpages. Data used by canRaise() and overlapped()
functions is only updated after YFrameWindow::setWinFocus() ends. When
RaiseOnFocus is true we know that the focused window will eventually
be raised and it is unnecessary to retain the button grab. This issue
remains for RaiseOnClickClient when RaiseOnFocus is false.

allencch · 2023-12-30 13:51:12

Just an update for this thread. With the icewm 3.4.5, this bug is resolved.

Arch Linux

#1 2023-12-26 13:11:55

[SOLVED] Browsers cannot click some small HTML elements

#2 2023-12-26 13:43:36

Re: [SOLVED] Browsers cannot click some small HTML elements

#3 2023-12-26 19:46:47

Re: [SOLVED] Browsers cannot click some small HTML elements

#4 2023-12-27 04:59:42

Re: [SOLVED] Browsers cannot click some small HTML elements

#5 2023-12-27 05:00:17

Re: [SOLVED] Browsers cannot click some small HTML elements

#6 2023-12-27 05:02:23

Re: [SOLVED] Browsers cannot click some small HTML elements

#7 2023-12-27 07:57:01

Re: [SOLVED] Browsers cannot click some small HTML elements

#8 2023-12-27 09:15:44

Re: [SOLVED] Browsers cannot click some small HTML elements

#9 2023-12-27 14:19:13

Re: [SOLVED] Browsers cannot click some small HTML elements

#10 2023-12-27 15:44:01

Re: [SOLVED] Browsers cannot click some small HTML elements

#11 2023-12-28 05:32:13

Re: [SOLVED] Browsers cannot click some small HTML elements

#12 2023-12-28 07:03:32

Re: [SOLVED] Browsers cannot click some small HTML elements

#13 2023-12-28 08:42:59

Re: [SOLVED] Browsers cannot click some small HTML elements

#14 2023-12-28 13:24:24

Re: [SOLVED] Browsers cannot click some small HTML elements

#15 2023-12-28 16:00:59

Re: [SOLVED] Browsers cannot click some small HTML elements

#16 2023-12-28 16:57:58

Re: [SOLVED] Browsers cannot click some small HTML elements

#17 2023-12-28 17:09:26

Re: [SOLVED] Browsers cannot click some small HTML elements

#18 2023-12-28 20:01:07

Re: [SOLVED] Browsers cannot click some small HTML elements

#19 2023-12-29 02:19:51

Re: [SOLVED] Browsers cannot click some small HTML elements

#20 2023-12-29 07:51:45

Re: [SOLVED] Browsers cannot click some small HTML elements

#21 2023-12-29 13:41:24

Re: [SOLVED] Browsers cannot click some small HTML elements

#22 2023-12-30 13:51:12

Re: [SOLVED] Browsers cannot click some small HTML elements

Board footer