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)
Core
DOM: Selection
Tracking
()
VERIFIED
FIXED
mozilla1.9alpha1
People
(Reporter: Brade, Assigned: uriber)
References
(Blocks 3 open bugs)
Details
(Whiteboard: [EDITORBASE-])
Attachments
(1 file)
(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").
Updated•25 years ago
|
Severity: normal → enhancement
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M15
Reporter | ||
Updated•25 years ago
|
Priority: P3 → P2
Target Milestone: M15 → M16
Comment 4•25 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
Updated•25 years ago
|
Target Milestone: M20 → Future
Comment 10•25 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 13•24 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 16•24 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 20•22 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•22 years ago
|
||
Mats, that "feature" of MSIE is a constant annoyance for me; please don't implement it in Mozilla.
Comment 22•22 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 25•22 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•22 years ago
|
Whiteboard: EDITORBASE → [EDITORBASE-]
Comment 28•22 years ago
|
||
Comment 3: no, triple-click selects a line, so triple-click-drag should select by lines, not paragraphs.
Comment 32•20 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.
*** Bug 305960 has been marked as a duplicate of this bug. ***
Blocks: 330968
Comment 38•19 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'.
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•18 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: 18 years ago
Resolution: --- → FIXED
Target Milestone: Future → mozilla1.9alpha
Comment 43•18 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•18 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).
Assignee | ||
Comment 46•18 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•18 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•18 years ago
|
Keywords: helpwanted
Comment 49•17 years ago
|
||
Verified fixed using Mac Thunderbird version 3.0a1pre (2008011903).
Status: RESOLVED → VERIFIED
Comment 50•17 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•17 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
•