Padblocker: Closing a window or tab swallows mouse click for splitsecond

[humdinger]

This is hrev56194, 64bit.

I've noticed that a while back, but I don't think it was always like this. I see it with Web+ very often:

• Start Web+ and open a few tabs.
• Hover your mouse pointer over a menu item, e.g. "Bookmarks".
• ALT+W to close the current tab, and immediately click on the "Bookmarks" menu item.

--> The menu doesn't open.

It looks like any click within maybe 1/4 of a second is lost.

Works with windows as well. For example, open two StyledEdit windows, close one with ALT+W and immediately click on a menu item in the left over StyledEdit window.

Not sure about the category for this ticket, guessing app_server.

[humdinger]

I tried to find out when this bad behaviour was introduced. Beta3 shows the same behaviour, Beta2 doesn't. However, the nightlies around Beta2 (hrev54707) also show this extremely annoying behaviour; hrev54715 and even before the Beta2 release, hrev54705.

Weird.

[humdinger]

Eureka! I found the cause for this thing that drove me nuts:
I had the PadBlocker 3rd party package installed and a while back (hrev54355 + hrev54357) this input server filter was added to the official Haiku image. I therefore had two "padblockers" which apparently interferred with each other.

[humdinger]

A question though: does the 3rd party package at HaikuPorts have to be disabled for <= r1~beta3_pm_hrev54357 ? What's with the padblocker package at ​build/jam/repositories/HaikuPorts/x86, shouldn't that be removed as well?

[waddlesplash]

We should likely disable the package at HaikuPorts altogether, yes.

The entry in the "x86" file is harmless. That file should get deleted at some point anyways, it's useless now.

[humdinger]

We should likely disable the package at HaikuPorts altogether, yes.

Shouldn't it keep being available for people with nightlies <= hrev1~beta3_pm_hrev54357 and beta3 users (until beta4 is out)?

[humdinger]

FYI, the recipe was ​changed accordingly.

[humdinger]

Re-opening this one, because I see this on beta4. Can anyone reproduce?

I have to add: The Input preferences only show one AT Keyboard, two USB Keyboards, one PS/2 Mouse and one USB Mouse. My notebook's touchpad isn't recognized as such (but works, without two-finger scrolling etc.) and I use a USB mouse.

If anyone's touchpad appears as such in the Input preferences, is there a setting "Keyboard Lock Delay" that might cause what's described in this ticket with certain settings?

[humdinger]

Blocklisting add-ons/input_server/filters/padblocker works around the problem.

[Zardshard]

Can reproduce. This causes bug #18377.

The trouble with padblocker is, it seems to run whether or not you have a touchpad, and, based off of the screenshot at ​https://www.haiku-os.org/docs/userguide/en/preferences/input.html#touchpad , there are no settings to disable it.

[humdinger]

based off of the screenshot at ​​https://www.haiku-os.org/docs/userguide/en/preferences/input.html#touchpad, there are no settings to disable it.

Sadly, my touchpad isn't recognized as such, so I can't test. But I think, if you smash the lock delay slider to right - "Never" - the locking is disabled.

[waddlesplash]

This may be fixed by hrev58319.

[Hanicef]

Replying to waddlesplash:

This may be fixed by hrev58319.

Unfortunately, after doing some proper testing, that patch won't fix this properly, it only eliminates one of it's symptoms. ​https://review.haiku-os.org/c/haiku/+/8557 is a proper fix for this bug.

[waddlesplash]

Fixed in hrev58336.