Closed
Bug 16203
Opened 23 years ago
Closed 16 years ago
double-click drag should do selection in "word-by-word" mode
Categories
(Core :: DOM: Selection, defect, P2)
Core
DOM: Selection
Tracking
()
VERIFIED
FIXED
mozilla1.9alpha1
People
(Reporter: Brade, Assigned: uriber)
References
(Blocks 3 open bugs)
Details
(Whiteboard: [EDITORBASE-])
Attachments
(1 file)
5.81 KB,
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").
Updated•23 years ago
|
Severity: normal → enhancement
Comment 1•23 years ago
|
||
This is also the behavior of Word '98. Marking as "Enhancement".
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M15
Comment 2•23 years ago
|
||
setting to M15, we can look at this later
Reporter | ||
Updated•23 years ago
|
Priority: P3 → P2
Target Milestone: M15 → M16
Comment 3•23 years ago
|
||
Similarly, triple-click-drag should select in paragraph-by-paragraph mode.
Comment 4•22 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.
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•22 years ago
|
||
changing status of bug since this is an enhancement request
Updated•22 years ago
|
Target Milestone: M20 → Future
Comment 10•22 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•22 years ago
|
||
*** Bug 23784 has been marked as a duplicate of this bug. ***
Comment 13•22 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•22 years ago
|
||
*** Bug 51216 has been marked as a duplicate of this bug. ***
Comment 15•21 years ago
|
||
*** Bug 75922 has been marked as a duplicate of this bug. ***
Comment 16•21 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.
Keywords: mozilla1.1
Comment 18•20 years ago
|
||
*** Bug 146388 has been marked as a duplicate of this bug. ***
Comment 19•20 years ago
|
||
*** Bug 146787 has been marked as a duplicate of this bug. ***
Comment 20•20 years ago
|
||
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•20 years ago
|
||
Mats, that "feature" of MSIE is a constant annoyance for me; please don't implement it in Mozilla.
Comment 22•20 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 24•20 years ago
|
||
And *please* don't deselect by character.... Max.
Comment 25•20 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•20 years ago
|
Whiteboard: EDITORBASE → [EDITORBASE-]
Comment 26•20 years ago
|
||
*** Bug 164998 has been marked as a duplicate of this bug. ***
Comment 27•20 years ago
|
||
*** Bug 166167 has been marked as a duplicate of this bug. ***
Comment 28•20 years ago
|
||
Comment 3: no, triple-click selects a line, so triple-click-drag should select by lines, not paragraphs.
Comment 29•19 years ago
|
||
*** Bug 225347 has been marked as a duplicate of this bug. ***
Comment 30•19 years ago
|
||
*** Bug 235934 has been marked as a duplicate of this bug. ***
Comment 31•18 years ago
|
||
*** Bug 264373 has been marked as a duplicate of this bug. ***
Comment 32•18 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•17 years ago
|
||
*** Bug 305363 has been marked as a duplicate of this bug. ***
*** Bug 305960 has been marked as a duplicate of this bug. ***
Comment 35•17 years ago
|
||
*** Bug 313420 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 36•16 years ago
|
||
*** Bug 329999 has been marked as a duplicate of this bug. ***
Blocks: 330968
Comment 37•16 years ago
|
||
This bug has been here since 1999. What's holding it up?
Comment 38•16 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•16 years ago
|
||
Piggybacking on the MaintainSelection mechanism.
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•16 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
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: Future → mozilla1.9alpha
Comment 42•16 years ago
|
||
Any chance of checking this in on the current branch(es)?
Comment 43•16 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•16 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•16 years ago
|
||
Has this been fixed for FireFox, SeaMonkey or both?
Assignee | ||
Comment 46•16 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•16 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•16 years ago
|
Keywords: helpwanted
Comment 49•15 years ago
|
||
Verified fixed using Mac Thunderbird version 3.0a1pre (2008011903).
Status: RESOLVED → VERIFIED
Comment 50•15 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•15 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.
You need to log in
before you can comment on or make changes to this bug.
Description
•