Word select not interrupted by lengthy mouse move (bad click count?)

VERIFIED DUPLICATE of bug 39192

Status

()

Core
Editor
P3
normal
VERIFIED DUPLICATE of bug 39192
17 years ago
16 years ago

People

(Reporter: jamacht, Assigned: rubydoo123)

Tracking

({helpwanted})

Trunk
mozilla0.9
x86
Windows 98
helpwanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
build: 2000080712 (M17)
reproducability: always

steps to reproduce:
load any web page, for instance www.mozilla.org
select a location overtop of any word and move the mouse there
single click, 
move cursor away, 
move back to the previous location, 
single click

result: word will be selected
expected result: word should not be selected

The mouse move can be interminably long in duration.

This also happens for line select. If this is a separate bug i'll file another.

Comment 1

17 years ago
confirming, win95 080908
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 2

17 years ago
this happens becuase we preserve the focus within the page, you can see this 
more clearly if you select a word and then move the focus to another document or 
even the location field.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID

Comment 3

17 years ago
verified in 8/16 build.
Status: RESOLVED → VERIFIED

Comment 4

17 years ago
That behavior seems unexpected to me though... it's not what I'd expect.  Why is 
that the behavior?
(Reporter)

Comment 5

17 years ago
Double click to select a word is industry-standard. Single-click then move for 
two minutes then click again performing a double click is non-standard and a 
little bit unjustified. I'd like a little justification if being non-standard 
and unexpected is better than being standard. 
(Assignee)

Comment 6

17 years ago
the way we set selection is to remember what the individual selected, you select 
something, move out of the active window, or select within the lacation bar and 
that selection is remembered. You could go away for a week and comeback to that 
previously active window and your selection will be remembered -- that has 
nothing to do with how words and lines are selected.

If you remain in the same window and set focus elsewhere, then yes the previous 
selection is not remembered.

Single-click sets the caret (focus)
Double-click selects the word
Triple-click selects the line
(Reporter)

Comment 7

17 years ago
I'm thinking you're confused about the bug. 

An initial double click never takes place. Therefore, a word should not be 
selected. 

The focus does not change at all during the whole 'steps to reproduce' section.


(Assignee)

Comment 8

17 years ago
ahh -- you're right, I was misreading it, single click, wait forever, single 
click again, it is annoying but we can wait to get it fixed. Setting to future 
and asking for helpwanted
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
(Assignee)

Updated

17 years ago
Status: REOPENED → ASSIGNED
Keywords: helpwanted
Target Milestone: --- → Future

Comment 9

17 years ago
Why is this an editor bug?  If this is coming across as a double-click event
(clickCount == 2), then seems like an xpfe bug.  If it's coming across as a
single click (clickCount == 1) yet we're still doing a word select, then it's a
selection bug (editor people, but not component editor).  Has anyone looked to
see what's really happening?
(Assignee)

Comment 10

17 years ago
no, no one has done any investigation as to why, had expected mjudge to look at 
it and see what is the issue, but that can wait

Comment 11

17 years ago
can anyone reproduce this bug with a recent build?  I think this bug was fixed
somewhere along the way....
Summary: Word select not interrupted by lengthy mouse move → Word select not interrupted by lengthy mouse move (bad click count?)
Target Milestone: Future → mozilla0.9
(Reporter)

Comment 12

17 years ago
Still reproducable for me, Build 2000112304, Windows 2000.

Comment 13

17 years ago
See also bug 53485.

Comment 14

17 years ago
Turns out this is a dup of 39192 and it is now fixed.

Comment 15

17 years ago
Oops, forgot to mark it dup

*** This bug has been marked as a duplicate of 39192 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → DUPLICATE

Comment 16

17 years ago
The behavior is still off in a build I just pulled -- the interval between two 
clicks such that it's counted as a double click seems far too long, noticeably 
longer than other apps on Windows.  This is visible in text selection -- when 
you select all of the text in the URL bar, for example, then pause, then click 
the selection, the text remains selected instead of deselecting.  Would that be 
outside the scope of this bug, and would that be a widget/window or a selection 
problem?  (It sounds to me like the former, since I assume selection is just 
handling the dbl click...)

Comment 17

17 years ago
Don't use the URL bar as an example, because I think they are doing things with 
the selection on that. verify that it is still aproblem on some text. The length 
of time inbetween is determined by a MS-Windows system call. It does seem long, 
but that is what the system defines.

Comment 18

17 years ago
What I said applies to all textfields.  It also seems a bit long with text on 
webpages, but not as noticeable.  So I guess it's a selection thing?

Comment 19

17 years ago
Seems to be windows-only -- at least, if I drag-select everything in a text
field, then quickly click back somewhere in the text field, I get the caret
positioned to the point nearest where the last click was, as I expected.

Selection code is XP and doesn't handle any click timeouts, so it's more likely
a toolkit issue.

Comment 20

17 years ago
Blake, how long are you pausing?  If you're not pausing for long, you might be 
running into bug 53485 on normal text and bug 62491 (plus 53485) in the 
location bar.  

(I assume you don't have browser.urlbar.clickSelectsAll on.  If you do, you're 
probably hitting bug 62493 in the location bar.)

Comment 21

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