wmii failure in pulldown menus?

[markvanatten]

On Arch 6.5.3 and with wmii pulled from here and compiled today, clicking in pulldown menus of certain websites no longer works correctly. Example: CTAN, hover over any of the menus on top (Cover, Upload, Browse, Search), and try to select one of their items. Clicking has no effect anymore, with, remarkably, the occasional exception. It works as expected with the other window managers I have tested today (rio, dwm, openbox, xmonad); and I have tested this with both Firefox and Chrome.

[0intro]

This is interesting. I'm experiencing this issue as well, but I haven't suspected the window manager. Did it work with a previous version of wmii?

[markvanatten]

I just compiled the version at https://code.google.com/archive/p/wmii/source/default/source and it shows the same problem. On the other hand, I have actively used earlier versions of wmii (than the one at the present repo) and I do not recall having run into this during my frequent visits to CTAN. But that is just my fallible memory.

[0intro]

I have a similar experience. It started to happen at some point. I suppose it could be related to the wmii dependencies, or a feature that is used by the modern browsers that wmii doesn't handle correctly.

[markvanatten]

In midori 9.0 it works. https://github.com/midori-browser/core

[0intro]

It might be that firefox and chromium uses an API to display these menus that midori don't. Once we figure out what is this feature, we could investigate on why it's not handled properly by wmii.

[markvanatten]

Also, but now independently of the website because it is in Firefox itself (117.0.1): regularly, when attempting to close a tab by clicking on the x in the tab title, the page remains open and all tab titles shift a bit to the right. (Tested in Firefox' Troubleshoot mode.) This problem does not occur in Chrome. As with the other reported issue, I do not see this phenomenon in rio or dwm.

[0intro]

I've located the issue. It seems to happen after XAllowEvents in the bdown_event function.

I don't know how to fix it yet, unfortunately.

[clemente]

I'll clarify that we're dealing not with dropdowns in <select> elements, but with CSS menus implemented with the :hover pseudo-class. The menu disappears faster than you can click, and the click doesn't get through.

It also makes other things hard to click, e.g. clicking airplanes in https://www.flightradar24.com/ is broken, maybe for the same reason (and the strong click workarounds mentioned above don't work).

I attach an HTML with another example; it comes from an OpenWRT router UI. The CSS may be a bit complex (absolute, float, left: -9999px) but it works fine except when this wmii bug happens. github didn't let me attach an .html so I compressed it with gzip. unclickable.html.gz

This wmii bug started happening in Firefox 110. I tried different Firefox versions in GNU/Linux under Xorg; 119.0.1 doesn't show the bug, but the next one (110.0) has the bug. 110.0.1 too. This is what changed in Firefox 110 : https://www.mozilla.org/en-US/firefox/110.0/releasenotes/

I tried disabling several settings in Firefox 110.0 to see if the bug stops happening, but it didn't. Sometimes I thought that I saw better results but it was illusory. This is the list of new settings I applied and didn't work:

• gfx.canvas.accelerated: false
• webgl.disabled: true
• webgl.enable-webgl2: false
• gfx.offscreencanvas.enabled: false
• gfx.canvas.willreadfrequently.enabled: false
• privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts: false
• browser.preferences.defaultPerformanceSettings.enabled: false

I didn't try different Chromium versions but I see that in 123.0.6312.86 the bug happens.

Workarounds, and how to relearn clicking on things:

• this usually works:
  1. right-click on the website background (a Firefox contextual menu appears) and don't release the button
  2. move the pointer away and press+release the left button, to dismiss the contextual menu
  3. while still holding the right button, point to the desired link, and click normally with the left button (press+release). This click will work
  4. you may release the right button now, or keep it pressed until you can patch wmii with a fix…
• something else that increases the chances of a successful click, without abusing the right button, is: click immediately after moving the mouse. It needs to be very fast; I'm speaking about 50 ms or so. If you stop the mouse and then click a link, it's almost guaranteed it won't work
• try other browsers. E.g. Falkon 22.12.1 doesn't show this bug
• try other window managers

This bug doesn't happen in i3, which I read is derived from wmii. Actually I didn't find references to XAllowEvents in i3's code. i3 documentation says that it was created because some wmii bugs were hard to fix. I have used wmii for 15 years and never had a reason to change but this bug may be one.

I've located the issue. It seems to happen after XAllowEvents in the bdown_event function.

For those not familiar with X protocol, could someone explain why the code triggers this bug?

Is it because wmii "grabs the pointer" when it shouldn't? XAllowEvents accepts several event_mode (doc.). Why does the code use ReplayPointer there? Would switching to another mode make sense and avoid this bug?