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)
Tracking
()
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.
Comment 1•25 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•25 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.
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•25 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•25 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 5•25 years ago
|
||
Thanks! (marked as Confirmed)
Comment 6•25 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•25 years ago
|
||
dup
*** This bug has been marked as a duplicate of 37338 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•