Closed Bug 36382 Opened 25 years ago Closed 25 years ago

Selecting text in a form does not stop when mouse button released

Categories

(Core :: DOM: Selection, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED DUPLICATE of bug 37338

People

(Reporter: mikebabcock, Assigned: pavlov)

Details

If I click somewhere inside a form (like this one) and drag the mouse, the highlight follows as it should. If, however, I move the mouse outside the "box" while I am 'dragging', and subsequently let go of the button, the "released" event must not be transmitted to the form item because when the mouse pointer returns over the text I was highlighting, the highlight moves with the cursor, even though the mouse button is up.
Mike, unfortunately, I don't quite understand this bug report. Is it perhaps a duplicate of 29300? If not, could you please review the Bug Writing Guidelines and resubmit or clarify? What do you mean by a 'box'? By a form, do you mean a TEXTAREA, or a web page that happens to be a form? What build are you using? (etc) thanks!
No, it is not the same as 29300 at all (although it might be related in the code for mouse handling, esp. dragging). The issue is related to textarea or any other text "area" in forms; <FORM TYPE=INPUT> or TYPE=TEXTAREA both. If the mouse button is released (while dragging to highlight) outside the input "boxed" area, the highlight continues to move with the mouse when the mouse re-enters the "boxed" area.
i see this on linux build ID 2000042609 - it's been there for a while: Here an easy way to reproduce: Click down and select text in URL field - do not release mousebutton Now move cursor out of the URL field (while still holding button in) NOW let go of the button but do NOT click anywhere else... and move the cursor - no buttons pressed - slowly left and right over the original selection. You will see that the selecting-event got "glued" to the cursor and selects/deselects according to your movements. Seems bug 37338 is about the same phenomena but with another approach to reproduce. The event doesn't realize pressure was released from the mousebutton "long ago".
I can't say for certain, as I haven't looked at the code in a long time, but I'd guess the cross-platform interface code is to blame. I'd be looking at which widgets are getting the mouse_release event and not passing it on. In programming terms (in my experience), the textarea (for example) widget is receiving the "mouse button 1 pressed" event and starting its highlight code treatment. When the mouse cursor leaves that area, everything's still fine. However, when the mouse button is released, the release event is now being given to a different component of the UI, and definately not to the widget the button had been depressed in. This message must be forwarded to all widgets that it MAY be appropriate to forward it to -- and/or actually have a global function that keeps track of "who" received the last mouse button-depressed event.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Thanks! (marked as Confirmed)
Pav -- I think this is a dup of 37338, but you'll be better qualified to determine if it is the same offending code.
Assignee: mjudge → pavlov
dup *** This bug has been marked as a duplicate of 37338 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Verified duplicate.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.