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

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.

verified in 8/16 build.

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

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....

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 ***

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.