Opened 2 years ago
Last modified 37 hours ago
#17821 reopened bug
Padblocker: Closing a window or tab swallows mouse click for splitsecond
| Reported by: | humdinger | Owned by: | axeld |
|---|---|---|---|
| Priority: | normal | Milestone: | Unscheduled |
| Component: | Servers/input_server | Version: | R1/beta4 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
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.
Change History (12)
comment:1 by , 2 years ago
comment:2 by , 2 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
comment:3 by , 2 years ago
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?
comment:4 by , 2 years ago
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.
comment:5 by , 2 years ago
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)?
comment:7 by , 22 months ago
| Component: | Servers/app_server → Servers/input_server |
|---|---|
| Resolution: | invalid |
| Status: | closed → reopened |
| Summary: | Closing a window or tab swallows mouse click for splitsecond → Padblocker: Closing a window or tab swallows mouse click for splitsecond |
| Version: | R1/beta3 → R1/beta4 |
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?
comment:8 by , 22 months ago
Blocklisting add-ons/input_server/filters/padblocker works around the problem.
comment:9 by , 15 months ago
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.
comment:10 by , 15 months ago
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.
comment:12 by , 37 hours ago
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.
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.