Closed Bug 117649 Opened 23 years ago Closed 2 months ago

Bad assumption: #button up events == #button down events

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

x86
Windows 2000
defect

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: zephod, Unassigned)

Details

From experience as a developer of X-Windows servers on PC's I have experienced the problem of a mismatch in button down and button up events in Windows. I have noticed that sometimes this seems to be causing the mouse to be 'stuck' to the scroll bars even after the mouse button is released (button-up). There is no guarantee of a mouse up event from windows under some conditions. Our solution involved checking the state of the buttons before processing mouse moves during a supposed button down state. Although this is a minor problem that repairs itself by clicking the mouse somewhere else, improper handling of button events may be causing some other more obscure problems for you on Windows platforms.
Tracking is _so_ the wrong component for this... Over to event handling.
Assignee: chofmann → joki
Component: Tracking → Event Handling
QA Contact: chofmann → madhur
related/dup: bug 29300, bug 43156, bug 41577, bug 48037. (Some of them likely dups of eachother)
QA Contact: madhur → rakeshmishra
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: rakeshmishra → trix
.
Assignee: joki → saari
QA Contact: trix → ian
Assignee: saari → nobody
QA Contact: ian → events
Component: Event Handling → User events and focus handling
Severity: normal → S3

Please file a new bug if this is still reproducible and kindly provide concrete STRs.

Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.