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

VERIFIED FIXED in mozilla1.9alpha1

Status

()

Core
Selection
P2
normal
VERIFIED FIXED
18 years ago
9 years ago

People

(Reporter: Kathleen Brade, Assigned: Uri Bernstein (Google))

Tracking

(Blocks: 3 bugs)

Trunk
mozilla1.9alpha1
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [EDITORBASE-])

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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").

Updated

18 years ago
Severity: normal → enhancement

Comment 1

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

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M15

Comment 2

18 years ago
setting to M15, we can look at this later
(Reporter)

Updated

17 years ago
Priority: P3 → P2
Target Milestone: M15 → M16

Comment 3

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

Comment 4

17 years ago
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.
Severity: enhancement → major
Keywords: beta2
Priority: P2 → P1
Whiteboard: Composer feature work

Updated

17 years ago
Keywords: nsbeta2

Comment 5

17 years ago
this would be nice but i just dont have time. i am putting this off to m20 for 
revisit.
Keywords: beta2
Target Milestone: M16 → M20

Comment 6

17 years ago
changing status of bug since this is an enhancement request
Severity: major → enhancement
Keywords: nsbeta2
Priority: P1 → P2
Whiteboard: Composer feature work

Comment 7

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

Comment 8

17 years ago
moving to future milestone
Assignee: mjudge → beppe
Status: ASSIGNED → NEW

Updated

17 years ago
Target Milestone: M20 → Future

Comment 9

17 years ago
moving back to previous owner
Assignee: beppe → mjudge

Comment 10

17 years ago
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."
Severity: enhancement → normal

Comment 11

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

Comment 12

17 years ago
adding help wanted to the keywords
Keywords: helpwanted

Comment 13

17 years ago
*SPAM*: Changing the QA contact of all open/resolved Selection bugs from 
elig@netscape.com to BlakeR1234@aol.com.  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...
QA Contact: elig → BlakeR1234

Comment 14

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

Updated

17 years ago
Blocks: 56401

Comment 15

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

Comment 16

16 years ago
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

15 years ago
changing selection qa to tpreston.
QA Contact: blaker → tpreston

Updated

15 years ago
Keywords: mozilla1.1

Updated

15 years ago
Blocks: 73812

Comment 18

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

Comment 19

15 years ago
*** Bug 146787 has been marked as a duplicate of this bug. ***
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.
Mats, that "feature" of MSIE is a constant annoyance for me; please don't
implement it in Mozilla.

Comment 22

15 years ago
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.
Keywords: mozilla1.1

Comment 23

15 years ago
adding editorbase+
Whiteboard: EDITORBASE+

Comment 24

15 years ago
And *please* don't deselect by character....

Max.

Comment 25

15 years ago
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.
Whiteboard: EDITORBASE+ → EDITORBASE

Updated

15 years ago
Whiteboard: EDITORBASE → [EDITORBASE-]
*** Bug 164998 has been marked as a duplicate of this bug. ***

Comment 27

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

Comment 28

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

Comment 29

14 years ago
*** Bug 225347 has been marked as a duplicate of this bug. ***
*** Bug 235934 has been marked as a duplicate of this bug. ***

Comment 31

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

Comment 32

13 years ago
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

12 years ago
*** Bug 305363 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

12 years ago
Depends on: 300131
*** Bug 305960 has been marked as a duplicate of this bug. ***

Comment 35

12 years ago
*** Bug 313420 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 36

11 years ago
*** Bug 329999 has been marked as a duplicate of this bug. ***
Blocks: 330968

Comment 37

11 years ago
This bug has been here since 1999.

What's holding it up?

Comment 38

11 years ago
(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'.
(Assignee)

Comment 39

11 years ago
Created attachment 228666 [details] [diff] [review]
patch

Piggybacking on the MaintainSelection mechanism.
Assignee: mjudge → uriber
Status: NEW → ASSIGNED
Attachment #228666 - Flags: review?(roc)
Comment on attachment 228666 [details] [diff] [review]
patch

excellent!
Attachment #228666 - Flags: superreview+
Attachment #228666 - Flags: review?(roc)
Attachment #228666 - Flags: review+
(Assignee)

Comment 41

11 years ago
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
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Target Milestone: Future → mozilla1.9alpha

Updated

11 years ago
No longer depends on: 300131
(Assignee)

Updated

11 years ago
Depends on: 344384

Comment 42

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

Comment 43

11 years ago
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).
(Assignee)

Comment 44

11 years ago
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

11 years ago
Has this been fixed for FireFox, SeaMonkey or both?
(Assignee)

Comment 46

11 years ago
(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).
(Assignee)

Comment 47

11 years ago
(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.

Updated

11 years ago
Depends on: 348787
Keywords: helpwanted

Updated

9 years ago
Duplicate of this bug: 411672

Comment 49

9 years ago
Verified fixed using Mac Thunderbird version 3.0a1pre (2008011903).
Status: RESOLVED → VERIFIED

Comment 50

9 years ago
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.
(Assignee)

Comment 51

9 years ago
(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.

Updated

9 years ago
Blocks: 433966
Duplicate of this bug: 429760
You need to log in before you can comment on or make changes to this bug.