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)

x86
All
defect

Tracking

()

VERIFIED WORKSFORME

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?
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
Keywords: perf
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
m17
Target Milestone: --- → M17
This appears to be working with 2000061820
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Keywords: verifyme
Verified
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.