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

VERIFIED DUPLICATE of bug 37338

Status

()

P3
normal
VERIFIED DUPLICATE of bug 37338
19 years ago
18 years ago

People

(Reporter: mikebabcock, Assigned: pavlov)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
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

19 years ago
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!
(Reporter)

Comment 2

19 years ago
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

19 years ago
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".

(Reporter)

Comment 4

19 years 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.

Updated

19 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

19 years ago
Thanks! (marked as Confirmed)

Comment 6

19 years ago
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
(Assignee)

Comment 7

19 years ago
dup

*** This bug has been marked as a duplicate of 37338 ***
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE

Comment 8

18 years ago
Verified duplicate.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.