Closed Bug 200098 Opened 19 years ago Closed 16 years ago

Double click near beginning of word selects two words

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla1.9alpha2

People

(Reporter: KaiE, Assigned: uriber)

References

(Blocks 1 open bug)

Details

(Keywords: topembed+, Whiteboard: editorbase+ [see comment #15 for complete description])

Attachments

(2 files)

Open new composer
Enter
  abc def efg
Double click exactly at the beginning of "d".

Actual result:
  The selection is now "abc def"

Expected result:
  Only "def" is selected.


Do you agree this is a bug?
category -> selection
Component: Editor: Core → Selection
Whiteboard: editorbase
Confirmed with build 20030312 on Windows NT
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3) Gecko/20030312

It also works in a browser-window : when you double-click in the space between 2
words (like the 'new composer' in the first line of comment 0), you select either :
- the first word + 1 space (if you double-click on the first half)
- or the 2 words + the space in between (if you double-click on the second half).
--> mjudge (selection)
Assignee: jfrancis → mjudge
-> me
Assignee: mjudge → kaie
absolutely this is a bug. I wish i could fix it now but I have so many other
bugs. please fix this if you can. aim me if you get stuck
Status: NEW → ASSIGNED
Priority: -- → P2
Whiteboard: editorbase → editorbase+
QA Contact: sairuh → beppe
topembed+
Keywords: topembed+
Target Milestone: --- → mozilla1.5beta
*** Bug 208598 has been marked as a duplicate of this bug. ***
Depends on: 211032
I've noticed punctuation also plays a sloppy role in this

the, bad! selection. stops: at? the; punctuation 
On:
User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.5a) Gecko/20030723
Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.5a) Gecko/20030723

a related symptom of this bug: double-click in a multi-line
text-entry field (or new mail message composer), there is no
way to double-click select just the last word on a non-last
line.  Always some leading portion of the next line is also
selected (either leading whitespace, or if none the first
word of that next line).

Coupled with the original description of this bug, double-
click just prior to last word of a line, selects THREE words!:
the two adjacent to the click event plus the leading portion of
the next line.
It's not likely that I will work on editor/selection bugs in the near future.
Mass assining my bugs to nobody.

Assignee: kaie → nobody
Status: ASSIGNED → NEW
-->floppy (although he may want to reassign back to nobody or module owner)
Assignee: nobody → mozeditor
Extra info:

If the mouse pointer is either in the space between two words, or up to halfway
in the first letter of a word, then the previous word is also selected. (Try it
with a word beginning with 'm' to see it best!)

If the following word is a link, then double-clicking anywhere in the word
selects the link word too.
Keyboard selection (CTRL+Shift+RightArrow) overshoots last word on a line and
systematically selects with it the first word in the next line.

End of line is not respected.

This is apparent in both TB and FF.
fgsdfg dsfgsdfg dsfgsd
No longer depends on: 211032
Since most of the comments above describe other problems, I'll try to give a
concise and complete description of the problem this bug is actually about:

When double-clicking the left half of the first letter of a word, the clicked
word and the word to its left are both selected.

The same happens on Mac and Linux (i.e. when
layout.word_select.eat_space_to_next_word is false) when you double-click the
right half of the last letter in a word: the word to the right gets selected as
well.

Also, when double-clicking the space between two words, both words get selected.

-----------------------

Note that this was first reported as bug 22421 back in 1999, but incorrectly
duped to a bug concerning other word-selection problems.

The cause of this bug is that the same code is used for the "move by word"
feature (ctrl+right/left arrow), and for the "select word" (double-click)
feature. The logic for moving (backward) is "move to the beginning of the word,
unless you're already at the beginning of the word, in which case move to the
beginning of the previous word". The current problem arises because the second
half of this logic is also applied to selection, when it certainly shouldn't be.

When refactoring the caret movement code (bug 300131), we should make sure to
distinguish between these two cases, so that the "move to the previous/next word
if you're currently at the beginning/end of a word" logic would not be applied
in the case of selection (double-click).

This distinction will also be relevant to paragraphs, if we ever implement bug
305347.
Depends on: 300131
Summary: Double click selects two separate words → Double click near beginning of word, or between words, selects two words
Whiteboard: editorbase+ → editorbase+ [see comment #15 for complete description]
Small correction to the description above: On Windows, only clicking the right
half of the space between two words selects both words. On Mac/Linux. clicking
anywhere on the space selects both words.

The bug summary describes the situation on Windows, for simplicity.
Summary: Double click near beginning of word, or between words, selects two words → Double click near beginning of word selects two words
*** Bug 313413 has been marked as a duplicate of this bug. ***
(In reply to comment #16)
> Small correction to the description above: On Windows, only clicking the right
> half of the space between two words selects both words. On Mac/Linux. clicking
> anywhere on the space selects both words.
> 
> The bug summary describes the situation on Windows, for simplicity.

Uri, It seems that the mac behaviour have changed since the 1.7 branch. Mac behaviour used to be like windows (see bug 313413). Is the new behaviour (clicking anywhere on the space selects both words) intentional?
(In reply to comment #18)
> Uri, It seems that the mac behaviour have changed since the 1.7 branch. Mac
> behaviour used to be like windows (see bug 313413). Is the new behaviour
> (clicking anywhere on the space selects both words) intentional?

The behaviour change occured on the trunk shortly after 1.7 was branched: It happened on 2004-04-19, as a result of fixing bug 142120. I don't think the effect on double-click was intentional (the bug was about ctrl+arrow). 
Hardware: PC → All
Blocks: 322547
Attached file testcase
This bug also appears in branch.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060213 Firefox/1.5 - Build ID: 2006021305
Blocks: word-select
Blocks: 349353
Attached patch patchSplinter Review
When moving backwards to find the beginning of the word, first move one character forward, to ensure we'll be finding the beginning of this word, and not the beginning of the previous one.

This patch makes the behavior on Windows identical to that of IE and MS Word. Note that clicking the right half of the space selects the following word (this happens on IE/Word as well).

This also slightly changes (improves, IMO) the behavior on Mac/Linux: only clicking on the left half of the space or the right half of the preceding letter results in two selected words. A real fix for Mac is the subject of bug 349353.
Assignee: mozeditor → uriber
Status: NEW → ASSIGNED
Attachment #250368 - Flags: review?(roc)
Er, wait, does this work when the caret is at the end of a word?
(In reply to comment #23)
> Er, wait, does this work when the caret is at the end of a word?
> 

Yes, it does, because the "one char forward" step brings us to the beginning of the next word (assuming there's one space between the words), and then the "one word backward" step takes us to the beginning of the previous (i.e., the original) word.
This is true regardless of the value of layout.word_select.eat_space_to_next_word. 
Checked in:
Checking in mozilla/layout/generic/nsFrame.cpp;
/cvsroot/mozilla/layout/generic/nsFrame.cpp,v  <--  nsFrame.cpp
new revision: 3.692; previous revision: 3.691
done

Fixes for Mac/Linux should be handled in bug 349353.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
(In reply to comment #26)
> done

This bug is still reproducible in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5
That's because this has only been fixed on the trunk, not the 1.8 branch, so it is not included in Firefox 2. The first public release to include this will be Firefox 3.
Target Milestone: mozilla1.5beta → mozilla1.9alpha2
Hello,

I apologize for adding a comment to a closed item, but I am unsure of any other way of asking this.

The ability to select both before and after words by double-clicking in the space between them is a feature that I use every day.  I understand why it was "fixed" and am ok with that.  However, I'm curious to know if it is possible to revert this fix (for myself) via a FireFox Extension?

I know very little about Extensions, but am willing to give it a shot if it's even possible for this type of change to be reversed using this method.  If this sort of thing isn't possible to do via an extension, I'm guessing that I could still get the functionality back by (un)patching the source and compiling a build myself?  Or how about a flag in the about:config file that would allow FireFox 3 to remain consistent with all previous versions?

Thanks in advance for any tips!
(In reply to comment #29)
> The ability to select both before and after words by double-clicking in the
> space between them is a feature that I use every day.

This feature is still present in Firefox 3 (at least under Mac OS X), but you need to click exactly in the space between the two words. Clicking on the first letter of a word now selects only the word, as expected.
With:
Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8.1.19) Gecko/20081218 SeaMonkey/1.1.14
layout.word_select.eat_space_to_next_word = false

issue#1: unwanted trailing whitespace/newline still sometimes selected. In Comment #24 above are two span quoted lines from #23 ending with an empty line, "> " in the quoted format. Double-click 2nd half of the > and it selects "> \n" (paste it elsewhere to observe the newline).

issue#2, a don't care: Cannot double-click-select just a single character word (when there is a word adjacent to that half of the char you clicked in).
You need to log in before you can comment on or make changes to this bug.