Kai Engert (:KaiE:) Reporter
	Description • 22 years ago

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?

	Kai Engert (:KaiE:) Reporter
	Comment 1 • 22 years ago

category -> selection

	Jo Hermans
	Comment 2 • 22 years ago

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).

	kinmoz
	Comment 3 • 22 years ago

--> mjudge (selection)

	Kai Engert (:KaiE:) Reporter
	Comment 4 • 22 years ago

-> me

	mjudge
	Comment 5 • 22 years ago

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

	Kevin McCluskey (gone)
	Comment 6 • 22 years ago

topembed+

	Jason M. Abels
	Comment 7 • 21 years ago

*** Bug 208598 has been marked as a duplicate of this bug. ***

	Chris Casciano
	Comment 8 • 21 years ago

I've noticed punctuation also plays a sloppy role in this

the, bad! selection. stops: at? the; punctuation 

	reb
	Comment 9 • 21 years ago

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.

	Kai Engert (:KaiE:) Reporter
	Comment 10 • 21 years ago

It's not likely that I will work on editor/selection bugs in the near future.
Mass assining my bugs to nobody.

	Kathleen :Brade
	Comment 11 • 21 years ago

-->floppy (although he may want to reassign back to nobody or module owner)

	Joachim Noreiko
	Comment 12 • 20 years ago

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.

	Raanan Barzel
	Comment 13 • 19 years ago

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.

	Uri Bernstein (Google) Assignee
	Comment 14 • 19 years ago

fgsdfg dsfgsdfg dsfgsd

	Uri Bernstein (Google) Assignee
	Comment 15 • 19 years ago

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.

	Uri Bernstein (Google) Assignee
	Comment 16 • 19 years ago

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.

	Elmar Ludwig
	Comment 17 • 19 years ago

*** Bug 313413 has been marked as a duplicate of this bug. ***

	Stefan [:stefanh]
	Comment 18 • 19 years ago

(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?

	Uri Bernstein (Google) Assignee
	Comment 19 • 19 years ago

(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). 

	Loki
	Comment 21 • 19 years ago

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

	Uri Bernstein (Google) Assignee
	Comment 22 • 18 years ago

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.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 23 • 18 years ago

Er, wait, does this work when the caret is at the end of a word?

	Uri Bernstein (Google) Assignee
	Comment 24 • 18 years ago

(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. 

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 25 • 18 years ago

OK great!

	Uri Bernstein (Google) Assignee
	Comment 26 • 18 years ago

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.

	Roland Steiner
	Comment 27 • 17 years ago

(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

	Elmar Ludwig
	Comment 28 • 17 years ago

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.

	Ron Higgins
	Comment 29 • 16 years ago

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!

	Vincent Lefevre
	Comment 30 • 16 years ago

(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.

	reb
	Comment 31 • 16 years ago

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).