16203 - double-click drag should do selection in "word-by-word" mode

Status: VERIFIED FIXED

Description

[Kathleen Brade]

This was a common feature request in the editor which many people use in an
editor:

When double-clicking a word, if the second click is followed by a drag, the
selection should select in chunks of words rather than characters.  For example,
given the position between the two m's in common in the first sentence above, if
a user double-clicked at that position and then dragged to the q in request, the
selection would be "common feature request".  Dragging to the left would operate
in a similar manner ("This was a common").

Comment 1

[Eli Goldberg]

This is also the behavior of Word '98. Marking as "Enhancement".

Comment 2

[rubydoo123]

setting to M15, we can look at this later

Comment 3

[Matthew Paul Thomas]

Similarly, triple-click-drag should select in paragraph-by-paragraph mode.

Comment 4

[rubydoo123]

updating keyword and status whiteboard to reflect that this is a beta 2 feature 
work bug that the Composer team deems a must fix for beta 2.

Comment 5

[mjudge]

this would be nice but i just dont have time. i am putting this off to m20 for 
revisit.

Comment 6

[rubydoo123]

changing status of bug since this is an enhancement request

Comment 7

[Jesse Ruderman]

*** Bug 35023 has been marked as a duplicate of this bug. ***

Comment 8

[rubydoo123]

moving to future milestone

Comment 9

[rubydoo123]

moving back to previous owner

Comment 10

[Eli Goldberg]

Raising severity to 'normal', per comment by Avi in bug #35023:

"On the Mac, if you perform a click-and-a-half (rapidly press the mouse button, 
release, press and hold) you select the word that the mouse pointer is over, and 
when you move the mouse, you increase the selection, one word at a time.

In Mozilla (4/6/00 nightly build), when you click-and-a-half, you select the word 
under the mouse pointer, but once you start moving the pointer the selection is 
extended by characters, not words."

Comment 11

[mjudge]

*** Bug 23784 has been marked as a duplicate of this bug. ***

Comment 12

[rubydoo123]

adding help wanted to the keywords

Comment 13

[Blake Ross]

*SPAM*: Changing the QA contact of all open/resolved Selection bugs from 
[e-mail] to [e-mail].  After the many great years of service 
Eli has given to Mozilla, it's time for him to move on; he has accepted a 
position at Eazel.  We'll be sad to see him go, and I'll do my best to fill his 
spot...

Comment 14

[Matthew Paul Thomas]

*** Bug 51216 has been marked as a duplicate of this bug. ***

Comment 15

[rubydoo123]

*** Bug 75922 has been marked as a duplicate of this bug. ***

Comment 16

[Caspy7]

Could someone explain to me why Bug 75922 (in the above comment) is a duplicate 
of this bug?
75922 is a bug on a lack of expected behavior of [triple clicking] *in mozilla*, 
not necessarily desired behavior by most.  It is not an enhancement as this bug 
is.

Look at bug 32807 for a discussion of the behavior pertaining to triple 
clicking.

Comment 17

[Blake Ross]

changing selection qa to tpreston.

Comment 18

[R.K.Aa.]

*** Bug 146388 has been marked as a duplicate of this bug. ***

Comment 19

[Max Waterman]

*** Bug 146787 has been marked as a duplicate of this bug. ***

Comment 20

[Mats Palmgren (:mats)]

I would prefer to have it like IE6 does it - when extending the selection it
selects word-by-word *by default* and when dragging backwards towards the start
(narrowing the selection), it (un)selects character-by-character.
It works very well.

Comment 21

[Christian :Biesinger (don't email me, ping me on IRC)]

Mats, that "feature" of MSIE is a constant annoyance for me; please don't
implement it in Mozilla.

Comment 22

[Jeremy M. Dolan]

This was one of the two major nits eWeek reviewer Timothy Dyck had with Mozilla
1.1b. I encourage NSCP to reevaluate the target for this work, as it is standard
behavior in all other apps and makes CCP frustrating.

Comment 23

[saari (gone)]

adding editorbase+

Comment 24

[Max Waterman]

And *please* don't deselect by character....

Max.

Comment 25

[saari (gone)]

maybe I was too hasty in plussing (lack of sleep?), just leaving nominated.
Sounds like it needs to be discussed by people Smarter Than Me.

Comment 26

[Mats Palmgren (:mats)]

*** Bug 164998 has been marked as a duplicate of this bug. ***

Comment 27

[Olav Vitters]

*** Bug 166167 has been marked as a duplicate of this bug. ***

Comment 28

[Vaclav Dvorak]

Comment 3: no, triple-click selects a line, so triple-click-drag should select
by lines, not paragraphs.

Comment 29

[Jo Hermans]

*** Bug 225347 has been marked as a duplicate of this bug. ***

Comment 30

[Mats Palmgren (:mats)]

*** Bug 235934 has been marked as a duplicate of this bug. ***

Comment 31

[Ryan Polk (Quark)]

*** Bug 264373 has been marked as a duplicate of this bug. ***

Comment 32

[Peter da Silva]

This bug exists throughout the system, in all text input objects. On OS X this
is a particularly annoying inconsistency, but it seems to conflict with native
widgets on Windows as well.

Comment 33

[zug_treno]

*** Bug 305363 has been marked as a duplicate of this bug. ***

Comment 34

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

*** Bug 305960 has been marked as a duplicate of this bug. ***

Comment 35

[Elmar Ludwig]

*** Bug 313420 has been marked as a duplicate of this bug. ***

Comment 36

[Uri Bernstein (Google)]

*** Bug 329999 has been marked as a duplicate of this bug. ***

Comment 37

[Peter da Silva]

This bug has been here since 1999.

What's holding it up?

Comment 38

[Jo Hermans]

(In reply to comment #37)
> This bug has been here since 1999.
> 
> What's holding it up?
> 

Waiting for someone to write a patch, perhaps ? That's why it's marked 'helpwanted'.

Comment 39

[Uri Bernstein (Google)]

Created attachment 228666 [details] [diff] [review]
patch

Piggybacking on the MaintainSelection mechanism.

Comment 40

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 228666 [details] [diff] [review]
patch

excellent!

Comment 41

[Uri Bernstein (Google)]

Checked in to trunk:

Checking in layout/generic/nsFrameSelection.h;
/cvsroot/mozilla/layout/generic/nsFrameSelection.h,v  <--  nsFrameSelection.h
new revision: 1.4; previous revision: 1.3
done
Checking in layout/generic/nsSelection.cpp;
/cvsroot/mozilla/layout/generic/nsSelection.cpp,v  <--  nsSelection.cpp
new revision: 3.245; previous revision: 3.244
done
Checking in layout/generic/nsFrame.cpp;
/cvsroot/mozilla/layout/generic/nsFrame.cpp,v  <--  nsFrame.cpp
new revision: 3.657; previous revision: 3.656
done

Comment 42

[Greg K.]

Any chance of checking this in on the current branch(es)?

Comment 43

[Bill Barry]

Are we in a feature freeze for Firefox 2? If not this would be a good enhancement that could probably make it for the release (that patch doesn't look very complex).

Comment 44

[Uri Bernstein (Google)]

Sorry guys, but I don't think having this for 2.0 is realistic.

Although the patch itself isn't that complex, it does build upon previous (fairly complex) changes made to bidirectional editing code (on the trunk only). Trying to fix this without those fixes would yield erratic and inconsistent behavior in bidi text.

Also, it is my understanding that the policy is not to accept such back-end enhancements to the 1.8 (Firefox 2.0) branch. See for example bug 32807 comment 32 (on a similar enhancement made on the trunk, at a much earlier stage).

Comment 45

[Vaclav Dvorak]

Has this been fixed for FireFox, SeaMonkey or both?

Comment 46

[Uri Bernstein (Google)]

(In reply to comment #45)
> Has this been fixed for FireFox, SeaMonkey or both?
> 

Both (this is a core bug), but only on trunk (Firfox 3.0 / SeaMonkey 2.0).

Comment 47

[Uri Bernstein (Google)]

(In reply to comment #46) 
> Both (this is a core bug), but only on trunk (Firfox 3.0 / SeaMonkey 2.0).
> 

SeaMonkey 1.5, that is (probably). Sorry for the spam.

Comment 49

[Greg K.]

Verified fixed using Mac Thunderbird version 3.0a1pre (2008011903).

Comment 50

[Scheichi]

This is NOT fixed in Camino 1.5.4 [Version 2007112812 (1.5.4Int)], both the word and line selections still extend character-by-character.

Comment 51

[Uri Bernstein (Google)]

(In reply to comment #50)
> This is NOT fixed in Camino 1.5.4 [Version 2007112812 (1.5.4Int)], both the
> word and line selections still extend character-by-character.
> 

Camino 1.5.x is based on the Gecko 1.8.1 branch. This was only fixed for Gecko 1.9.