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

Status: VERIFIED DUPLICATE of bug 37338

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

Description

[Michael T. Babcock]

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.

Comment 1

[Eli Goldberg]

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!

Comment 2

[Michael T. Babcock]

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.

Comment 3

[R.K.Aa.]

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".

Comment 4

[Michael T. Babcock]

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.

Comment 5

[Eli Goldberg]

Thanks! (marked as Confirmed)

Comment 6

[rubydoo123]

Pav -- I think this is a dup of 37338, but you'll be better qualified to 
determine if it is the same offending code.

Comment 7

[Stuart Parmenter]

dup

*** This bug has been marked as a duplicate of 37338 ***

Comment 8

[Matt Perry]

Verified duplicate.