Closed Bug 16203 Opened 25 years ago Closed 18 years ago

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

Categories

(Core :: DOM: Selection, defect, P2)

Product:
Core
Component:
DOM: Selection
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.9alpha1

People

(Reporter: Brade, Assigned: uriber)

References

(Blocks 3 open bugs)

Details

(Whiteboard: [EDITORBASE-])

Attachments

(1 file)

patch
(deleted), patch
roc
: review+
roc
: superreview+
Details | Diff | Splinter Review 
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").
Severity: normal → enhancement
This is also the behavior of Word '98. Marking as "Enhancement".
Status: NEW → ASSIGNED
Target Milestone: M15
setting to M15, we can look at this later
Priority: P3 → P2
Target Milestone: M15 → M16
Similarly, triple-click-drag should select in paragraph-by-paragraph mode.

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
Keywords: nsbeta2
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
changing status of bug since this is an enhancement request
Severity: major → enhancement
Keywords: nsbeta2
Priority: P1 → P2
Whiteboard: Composer feature work
*** Bug 35023 has been marked as a duplicate of this bug. ***
moving to future milestone
Assignee: mjudge → beppe
Status: ASSIGNED → NEW
Target Milestone: M20 → Future
moving back to previous owner
Assignee: beppe → mjudge
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
*** Bug 23784 has been marked as a duplicate of this bug. ***
adding help wanted to the keywords
Keywords: helpwanted
*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
*** Bug 51216 has been marked as a duplicate of this bug. ***
Blocks: 56401
*** Bug 75922 has been marked as a duplicate of this bug. ***
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.
changing selection qa to tpreston.
QA Contact: blaker → tpreston
Keywords: mozilla1.1
Blocks: 73812
*** Bug 146388 has been marked as a duplicate of this bug. ***
*** 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.
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
adding editorbase+
Whiteboard: EDITORBASE+
And *please* don't deselect by character....

Max.
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
Whiteboard: EDITORBASE → [EDITORBASE-]
*** Bug 164998 has been marked as a duplicate of this bug. ***
*** Bug 166167 has been marked as a duplicate of this bug. ***
Comment 3: no, triple-click selects a line, so triple-click-drag should select
by lines, not paragraphs.
*** Bug 225347 has been marked as a duplicate of this bug. ***
*** Bug 235934 has been marked as a duplicate of this bug. ***
*** Bug 264373 has been marked as a duplicate of this bug. ***
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.
*** Bug 305363 has been marked as a duplicate of this bug. ***
Depends on: 300131
*** Bug 305960 has been marked as a duplicate of this bug. ***
*** Bug 313420 has been marked as a duplicate of this bug. ***
*** Bug 329999 has been marked as a duplicate of this bug. ***
This bug has been here since 1999.

What's holding it up?
(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'.
Attached patch patch (deleted) — — Splinter Review 
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+
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
Closed: 18 years ago
Resolution: --- → FIXED
Target Milestone: Future → mozilla1.9alpha
No longer depends on: 300131
Depends on: 344384
Any chance of checking this in on the current branch(es)?
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).
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).
Has this been fixed for FireFox, SeaMonkey or both?
(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).
(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.
Depends on: 348787
Verified fixed using Mac Thunderbird version 3.0a1pre (2008011903).
Status: RESOLVED → VERIFIED
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.
(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.
Blocks: 433966
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: