452948 - double clicking a word selects trailing white space

Status: RESOLVED INVALID

(Core :: DOM: Selection, defect)

Description

[Kuno Meyer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

Double clicking a word selects the trailing white space. While this behaviour is at least visible for *space characters*, it isn't for *new lines* (you cannot see whether the resulting selection contains the line break or not). This is particularly a bad behaviour if you are trying to select-copy-paste passwords, which tend to be at the end of a line and at the target input field is merely displaying bullets.

Reproducible: Always

Steps to Reproduce:
1. Go to <http://www.mozilla.org/>
2. Double click at "Looking" from "Looking for Firefox & Thunderbird"

Actual Results:  
The selection contains "Looking " (note the trailing space character)

Expected Results:  
The selection should be "Looking"

- I'm observing this in FF 3.0.1 and TB 2.0.0.16 (first in TB while coping the content of a "forgot password"-mail...)
- This bug is probably a dupe of bug 435704
- "layout.word_select.eat_space_to_next_word = true" in both apps

Comment 2

[Wayne Mery (:wsmwk)]

Kuno, do you see the problem in the latest FF 3.0.x? 
problem may have been introduced by bug 406062  and fixed by bug 432415.
see also Thunderbird bug 437679

Comment 3

[bugzilla]

The issue persists in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b5pre) Gecko/20090428 Shiretoko/3.5b5pre

Comment 4

[Kuno Meyer]

The issue still exists in [Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4 (.NET CLR 3.5.30729)], but I can give better instructions for reproduction:

- double clicking a word selects the word *and the trailing whitespace*
- double clicking the last word of a line *inside of a <pre> block* selects the trailing newline

(Use the attached test HTML file for reproduction)

Another very drastic case of selecting too much, which occurs right here in the HTML of bugzilla, is:
- log out of bugzilla
- go to this very bug we are talking about now
- right at the top of the page, there is a grey bar """[bug XXXX] - XXXX space - [Last Comment]""" (there is no "(edit)" after the word "space")
- double click the word "space", copy and paste into your favorite editor

Result: approx. 20 Lines of HTML (see below)

By the way: Bug 406062 and bug 432415 are not related here because they focus on pasting. This bug here is about the selection (or perhaps the copying) step.

------------------
space</span>

     </span>
  
       
    <div style="display: none;" id="summary_alias_input">
      <table id="summary"> 
          <tbody><tr>
            <td colspan="2">
          </td>
        </tr> 
        
        <tr>
          <td>
            <label accesskey="s" for="short_desc"><u>S</u>ummary</label>:
          </td>

          <td>double clicking a word selects trailing white space
          </td>
        </tr>
      </tbody></table>
    </div>

Comment 5

[Kuno Meyer]

Attachment: test case for reproduction

Comment 6

[long]

This is still happening with Firefox 3.6.10 and Seamonkey 2.0.8

Comment 7

[(no longer active)]

Firstly, this should live in Core::Selection.

This behavior is controlled by the layout.word_select.eat_space_to_next_word pref.  If it's set to true, word selection selects the trailing space as well.  The default value of this pref on Windows is true to match the platform default selection behavior, hence the behavior that you're seeing.  Changing the value to false should give you what you want.

Comment 8

[Marat Tanalin]

(In reply to comment #7)

It's very nice that about:config pref is available now (last time I poked about this bug, there was no known options for users to fix the bug locally themselves). Is it known when exactly has it been implemented?

As for defaults, it's not quite clear how exactly platform default selection behavior is determined. Native textual form-fields? Built-in applications like Notepad?

It probably makes sense to take into account that at least following popular _Windows_ applications do _not_ select trailing space after word (selected with double click) by default:

    1. Opera;
    2. Safari;
    3. PhpED;
    4. EmEditor;
    5. TopStyle;
    6. Adobe Reader.

where 1-2 are web browsers, 3-5 are popular programming-code editors, and 6 is mainstream PDF viewer.

Comment 9

[Peter Lemieux]

I encountered this annoyance when switching to a Windows version of Firefox from Linux.  I think the default behavior of Firefox should be the same across all platforms and not conform to the vagaries of the platform on which the program is running.  It is also not obvious how one determines the "platform default" in cases like this.  As Marat observes, other Windows programs do not include trailing white-space by default.  What constitutes the "platform default" for Windows?  Is it based on specifications from Microsoft?

I will now go and change the entry in about:config, but the Linux behavior of excluding trailing white space when double-clicking a word seems much more intuitive, and in practice it proves much more useful as well.

Comment 10

[Rob Crowther]

It may be the default for Windows, but at least MS Office there is further supporting behaviour: if you double click a word in (for example) an Outlook message and then type to replace the word, then the trailing space is *not* replaced even if it was part of the selection.  This means the common action of double clicking on a word and replacing it immediately works as you would reasonably expect - just the word is replaced, trailing spaces are untouched (and indicates that, at least in the case of Office developers, there are people at Microsoft that realize the default double click behaviour is dumb).

If insane Windows defaults are going to be used as Thunderbird defaults, could we also implement useful behavioural corollaries to those defaults?