Closed
Bug 39837
Opened 25 years ago
Closed 24 years ago
Fast mouse text hiliting in editboxes not working
Categories
(Core :: DOM: Selection, defect, P3)
Tracking
()
VERIFIED
WORKSFORME
M17
People
(Reporter: wd, Assigned: mjudge)
References
()
Details
(Keywords: perf)
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m16) Gecko/20000518
BuildID: 2000051820
When the text in a textbox is attempted to be hilited with the mouse very
quickly, it does not hilite. It just puts a blinking cursor at the end of the text
Reproducible: Always
Steps to Reproduce:
1.Go to http://bugzilla.mozilla.org/show_bug.cgi?id=22710
2.Before clicking anywhere, With a *quick* sweeping motion, try to hilite the
text in one of the text boxes. (click as the mouse is moving
3.
Actual Results: A blinking cursor is put at the end of the text, but it's not
hilited
Expected Results: The text is hilited
An interesting note: If you click anywhere on the page first, the hiliting
works fine. As fast as I can move the mouse, the entire text is hilited no
matter what. But if the page is not clicked on at all (after a re-load or
first bringing up the page), it exhibits the above behavior. Some sort of
focus issuse, perhaps?
Comment 1•25 years ago
|
||
First: to reproduce the problem, I need to move the mouse so fast that the only
control I have is to keep the pointer moving horizontally -- there is no way to
stop before travelling out of the textbox again.
Lowering severity to minor: this isn't going to happen for normal, controlled
selections. wdormann, please explain if you disagree.
It is possible to end up with no selection if the mouse moves *very* quickly
out of the textbox after the mousdown and the button is let up before returning
the pointer into the textbox. If the pointer is moved back into the textbox
before the mouse button is let up, a normal selection can be made even if no
highlighting took place while the pointer was moving through the first time.
Selecting more slowly, the editbox blanks and redraws immediately after the
mousedown of the drag; guessing that the problem described here only happens
if the pointer moves out of the editbox before that redraw happens, so this
probably *is* a problem with the speed at which focus is set.
Setting "perf" keyword and moving to "Selection" component.
Assignee: joki → mjudge
Severity: normal → minor
Component: Event Handling → Selection
QA Contact: janc → elig
Summary: Fast mouse text hiliting not working → Fast mouse text hiliting in editboxes not working
Sean,
I guess it's just the type of hiliting that I'm doing. I was going through
some of the "verifyme" bugs today, and what I'd do was this: As I would
verify a bug, I would clear out the Keywords box (if it only contained the word
"verify". So I'm not hiliting a particular selection or portion of the text
box, but the whole thing! So I'm not going to drag the mouse and make sure I
stop before I hit the end of the box... I'm just going to zip straight across.
So yes, I believe you are seeing the same behavior that I saw, since when I let
go of the mouse button, the mouse pointer is outside of the text box
Now, with Mozilla, with *every* single bug I went through, I'd have to go and
try to hilite the Keywords box twice. Very annoying. Neither NN nor IE
display this behavior. I don't believe that my actions are that out of the
ordinary. I don't work that fast, and I expect the software I'm using to be
able to keep up with me! ;-)
What's important to note, though, is that if I click *anywhere* within the
Mozilla window before trying to hilite the text, the hiliting works fine no
matter how fast I do it. (Trust me, I tried to move the mouse faster than
Mozilla could handle, but I couldn't do it! The text was 100% selected every
time)
Wouldn't it be possible to have Mozilla behave this way without having to click
first?
I guess this does fit the "minor" severity description. Though, I do run
across this problem on a near daily basis, and it is quite annoying.
OS: Windows 98 → All
This appears to be working with 2000061820
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•