My favorites ▼ | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 39795: When double-clicking to select a word, only the word should be selected
13 people starred this issue and may be notified of changes. Back to list
 
Reported by simon.bo...@gmail.com, Mar 30, 2010 
Chrome Version       : 4.1.249.1042 unknown (42199), 5.0.364.0 (Developer 
Build 42899)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 4: OK
  Firefox 3.6: FAIL
         IE 7: Varying, mostly FAIL
         IE 8: ?

What steps will reproduce the problem?
1. Double click on any word (but not a link)
2. Notice that depending on word context and underlying HTML source, you 
might get either just the word, the word + one space, or the word + a line 
break.
3. Optional bonus step: Copy & paste, and notice you need to stay alert to 
whether you get a space, newline or nothing at all.

What is the expected result?
Mark only the word and nothing more. That way the user can choose to hit 
space if the word is to be part of a text. Safari 4 does like this.

Also, a user that might like a space (but never new lines?) copied might be 
helped by typing their essays in a word processing software that takes care 
of magic adding of spaces at the end of pasted words, like for instance MS 
Word.


What happens instead?
You sometimes get a space, and sometimes get something that looked like a 
space but turns out to be a new line after you copy and paste it.


This bug created as per Evan's request, see 
https://code.google.com/p/chromium/issues/detail?id=72#c35
Mar 30, 2010
#1 dherber...@gmail.com 
Firefox has an option in their about:config page to toggle this functionality 
(layout.word_select.eat_space_to_next_word). 

As far as I know, Chromium doesn't have any analog to about:config to configure this 
manually. For me, it makes more sense to not eat the space after a word as the default.
Aug 12, 2010
#2 cody.le...@gmail.com 
I see this also.

IE8 and Firefox 3.6 select just the word. Safari 5.0. Gets just the word and maybe a line return? It correctly just copies the word, but the selection indicator looks like it goes outside the div.

Chrome will span into another DIV and grab select additional text.

6.0.472.33 (Official Build 55501) beta


See attached file and double click on the AST100393 in various browsers to see the behavior
index.html
470 bytes   View   Download
Aug 12, 2010
#3 phajdan.jr@chromium.org 
This reproduces with Google Chrome 6.0.472.25 dev on Mac OS X and doesn't look like correct behavior (although I'm not sure).
Status: Untriaged
Labels: -Area-Undefined Area-WebKit WebKit-Core
Aug 16, 2010
#4 ka...@chromium.org 
dimitir, just wanted to know your thoughts on this. let me know and i'll move to the appropriate milestone.
Owner: dglaz...@chromium.org
Labels: Mstone-7
Aug 23, 2010
#5 dglazkov@chromium.org 
Tony, Ojan, is this something we want to tackle for M7?
Owner: ---
Cc: tony.chromium o...@chromium.org
Aug 23, 2010
#6 tony@chromium.org 
I see, the bug appears to be that we select newlines after words when we should only be selecting spaces.  Seems like this should be an easy fix for M7.

cody.lerum, thanks for the test case!
Status: Available
Aug 23, 2010
#7 o...@chromium.org 
morita, rniwa, one of you interested in tackling this?
Cc: rn...@chromium.org morr...@google.com
Aug 24, 2010
#8 morrita@google.com 
OK, I'll take a look. WebKit side is filed at https://bugs.webkit.org/show_bug.cgi?id=44512.
Sep 15, 2010
#9 dglazkov@chromium.org 
(No comment was entered for this change.)
Labels: -Mstone-7 Mstone-8
Oct 19, 2010
#10 lafo...@chromium.org 
Since we are passed the branch, moving all mstone-8 issues to mstone-9 for triage/punting
Labels: -Mstone-8 Mstone-9
Oct 26, 2010
#11 ka...@chromium.org 
moving this to X. upstream bug still says new. if you're planning to work on it soon, oplease let me know.
Labels: WebkitBugFiled
Oct 29, 2010
#12 ka...@chromium.org 
(No comment was entered for this change.)
Labels: -Mstone-9 Mstone-X
Apr 9, 2011
#13 cody.le...@gmail.com 
anyone have an idea of how large of change this would be? Data input and extraction from webapps can be painful at times...
Jul 5, 2011
#14 simon.bo...@gmail.com 
@13: Notice "Labels: WebkitBugFiled" and morrita@G might have some ideas, otherwise https://bugs.webkit.org/show_bug.cgi?id=44512 and check with the webkit developers on their maillist perhaps

@morrita:  Issue 39794  is most likely interesting to look at as well.
Aug 25, 2011
#15 karol.ka...@gmail.com 
Strange thing:
1. double click on word in URL address bar:
- word plus separator is selected
- typing over replaces word only
2. double click on text in any input box
- word+space are selected,
- typing over replaces word+space.

Chrome 13.0.782.112 m
Aug 25, 2011
#16 simon.bo...@gmail.com 
(@15 my bug was about selecting in the webpage, not in the URL bar.
So better open a separate bug if you see bygs there. I quite like how url bar editing works, see if you doubleclick to select "test." out of a URL like something.../test.html. If you type new stuff without first hitting delete, the . or any similar separator isn't deleted in order to make it easy to edit an existing URL. If you hit delete first, the full selection is really removed.)
Nov 8, 2011
#17 rn...@chromium.org 
(No comment was entered for this change.)
Labels: -WebKit-Core WebKit-Editing
Mar 10, 2013
#18 bugdroid1@chromium.org 
(No comment was entered for this change.)
Labels: -Area-WebKit -WebKit-Editing Cr-Content Cr-Content-Editing
Apr 5, 2013
#19 bugdroid1@chromium.org 
(No comment was entered for this change.)
Labels: -Cr-Content Cr-Blink
Apr 5, 2013
#20 bugdroid1@chromium.org 
(No comment was entered for this change.)
Labels: -Cr-Content-Editing Cr-Blink-Editing
Jul 9, 2013
#21 yosin@chromium.org 
This is expected behavior on Windows for browser compatibility and Windows convention of double-clicking-to-select-word. IE and FireFox select as same as Chromium.

On Linux and Mac, Chromium selects only word.
Status: WontFix
► Sign in to add a comment

Powered by Google Project Hosting