Closed Bug 47966 Opened 24 years ago Closed 24 years ago

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

Categories

(Core :: DOM: Editor, defect, P3)

Product:
Core
Component:
DOM: Editor
Platform:
x86
Windows 98
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 39192
Milestone:
mozilla0.9

People

(Reporter: jamacht, Assigned: rubydoo123)

Details

(Keywords: helpwanted) 

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.
confirming, win95 080908
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
Closed: 24 years ago
Resolution: --- → INVALID
verified in 8/16 build.
Status: RESOLVED → VERIFIED
That behavior seems unexpected to me though... it's not what I'd expect.  Why is 
that the behavior?
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. 
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
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.



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 → ---
Status: REOPENED → ASSIGNED
Keywords: helpwanted
Target Milestone: --- → Future
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?
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
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
Still reproducable for me, Build 2000112304, Windows 2000.

See also bug 53485.
Turns out this is a dup of 39192 and it is now fixed.
Oops, forgot to mark it dup

*** This bug has been marked as a duplicate of 39192 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
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...)
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.
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?
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.
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.)
VERIFIED.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.