Closed Bug 3358 Opened 26 years ago Closed 26 years ago

Missed mouse up events cause chaos

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
PowerPC
Mac System 8.5
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: sfraser_bugs, Assigned: pierre)

Details

There is some weirdness with event handling a the moment which cause raptor to think that the mouse is still down, long after you've let go of the button. I assume it's because we process the mouse down event, the mouse up gets lost, so poor raptor never gets the NS_MOUSE_LEFT_BUTTON_UP event, and behaves as if the mouse is still down. I'm seeing this while debugging stuff that happens on a mouse click (like selection). I click, go into the debugger, run again, and now moving the mouse causes it to behave as if I was dragging out a selection. Most frustrating. If we leave it this way, I'm sure there'll be some sequence of normal user actions that triggers this.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → INVALID
The debugger eats your mouseUp events: that's what happened to me when I was working on event handling. Closed as Invalid.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Reopening. You must have missed my last comment -- there _will_ be some sequence of user actions, or interactions with some other software, that cause this bug to happen. The bug also makes it impossible to debug certain event handling operations. It is possible to reproduce the problem without the debugger. Simply mouse down in the raptor window, and drag the mouse outside of the window (onto the desktop). Now release the mosue button. Move back into the window, and you are in 'crazy select' mode. This makes me think that it's not that we miss the mouse up, but because the target window is different, we don't propagate it.
I've seen this a bunch. You can also get it by releasing the mouse sometimes in a different widget (within the same window) as the initial click. I'm sure the logic is similar to simon's example.
I'm working on it. The fix for mouseUp events in the html area is fairly simple but I want to fix the other small related problems with buttons (as described by Pink), with buttons after a drag and with scrollbars (as described in #2336).
Status: REOPENED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
Fixed
Status: RESOLVED → VERIFIED
This seems working fine now. Here is some test I conducted to verify. 1] Create HTML file with following contents. <html> <head> <title>Test innerWidth</title> </head> <script> <!-- function report(text) { var value=document.workform.result.value; var msg= value+ " " +text; document.workform.result.value=msg; } //--> </script> <body > <form name="workform" > <input type="button" name="TestButton" value=" TestButton " onMouseDown="report('MouseDown');" onMouseUp="report('Mouseup');" ><br> Result Text Box<INPUT TYPE=text NAME="result" SIZE=80> <input type="reset" value="Reset"> </form> </body> </html> 2] Open in apprunner/viewer. 3] Click on TestButton. Results: Result text box appropriate event happening of MouseDown and MouseUp events. Seems working fine now. Marking as verified.
Could you put that test on an available URL, and put it in the URL field. Also, the problem still occurs when debugging sometimes, so we're not bullet proof with respect to this problem. Perahps we should test whether the mouse is actually down when propagating certain events?
I think that we need to send mouseMoved events at all times, not just when the mouse button is pressed, in order to let some JS scripts change the cursor or do other things. The problem of missed mouseMoved events while working with breakpoints under debugger is not typical of our application.
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.