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").
This is also the behavior of Word '98. Marking as "Enhancement".
setting to M15, we can look at this later
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.
this would be nice but i just dont have time. i am putting this off to m20 for revisit.
changing status of bug since this is an enhancement request
*** Bug 35023 has been marked as a duplicate of this bug. ***
moving to future milestone
moving back to previous owner
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."
*** Bug 23784 has been marked as a duplicate of this bug. ***
adding help wanted to the keywords
*SPAM*: Changing the QA contact of all open/resolved Selection bugs from email@example.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...
*** Bug 51216 has been marked as a duplicate of this bug. ***
*** 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.
*** 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.
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.
*** 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. ***
*** 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'.
Created attachment 228666 [details] [diff] [review] patch Piggybacking on the MaintainSelection mechanism.
Comment on attachment 228666 [details] [diff] [review] patch excellent!
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
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.
Verified fixed using Mac Thunderbird version 3.0a1pre (2008011903).
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.