1043118 - Do not select leading/trailing spaces on double clicking.

Status: NEW

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

Description

[Hiroyuki Ikezoe (:hiro)]

Word selection on double clicking selects extra spaces in particular HTML codes like this:

<p>word  <br></p>

Comment 1

[Hiroyuki Ikezoe (:hiro)]

Attachment: bug1043118

Comment 2

[Hiroyuki Ikezoe (:hiro)]

try:
https://tbpl.mozilla.org/?tree=Try&rev=46e7e0a31aff

Comment 3

[Elbart]

Isn't this what layout.word_select.eat_space_to_next_word is for?

http://kb.mozillazine.org/Layout.word_select.eat_space_to_next_word

Comment 4

[Mats Palmgren (inactive)]

-    beginAmount = endAmount = eSelectWord;
+    beginAmount = endAmount = eSelectWordNoSpace;

"eat_space_to_next_word" is true by default on Windows, so I suspect the above
might break word selection on Windows. (I haven't tested the patch though.)

Comment 5

[Karl Dubost💡 :karlcow]

Something similar is happening here https://webcompat.com/issues/15406

This seems to be a duplicate of Bug 639579 but this one has a patch here.

Maybe related too.

* Bug 773559
* Bug 1192622


And this seems related to Bug 601586

If for example the textContent is 


"    ?05O*G0L0?L.vbW
  "

>> $0.textContent
"    ?05O*G0L0?L.vbW
  "
>> document.getSelection().toString()
" ?05O*G0L0?L.vbW "  /* Firefox */
>>  document.getSelection().toString()
"?05O*G0L0?L.vbW"  /* Chrome */

Comment 6

[Boris Zbarsky [:bzbarsky]]

toString() on selection is not specified, for what it's worth, so using it is not very helpful.  You'd have to look at the actual selection ranges to find out what's selected.

In any case, I'm not sure what info you're asking me for....

Comment 7

[Karl Dubost💡 :karlcow]

Why asking:
1. Because of the comment in https://bugzilla.mozilla.org/show_bug.cgi?id=601586#c1
2. Because I was wondering if you knew what would be the correct behavior. Chrome in a scenario of copy and paste, trim the leading and trailing space which creates issues when Firefox users are pasting a password for example.


>> $0.textContent
"   dooo doo bah 
     
     dah boum"

Select the dah with a double click.

>> window.getSelection().toString() /* Firefox */
" dah"
anchorOffset: 17
focusOffset: 31
rangeCount: 1


>> window.getSelection().toString() /* Chrome, Safari */
"dah"

/* Chrome */
anchorOffset: 28
baseOffset: 28
extentOffset: 31
focusOffset: 31
rangeCount: 1

/* Safari */
anchorOffset: 28
baseOffset: 29
extentOffset: 29
focusOffset: 31
rangeCount: 1



ah I see
https://www.w3.org/Bugs/Public/show_bug.cgi?id=10583
http://w3c.github.io/selection-api/#x4-selection-interface



So what do we use when we paste in a document.

Comment 8

[Mats Palmgren (inactive)]

Test results like that aren't very useful without knowing the platform.
Assuming it's Windows...  I seem to recall the reported behavior is
intentional there.  Does flipping the pref in comment 3 help?

On Windows, I think the behavior of text controls in Edge, and in
Windows UI, should guide our decision here, not Chrome.
Did you test those?

Comment 9

[Karl Dubost💡 :karlcow]

Ah! Thanks Mats. 
My tests in Comment #7 are on macOS 10.13.3 (17D47)
with Firefox Nightly 60.0a1 (2018-02-20) (64-bit)

For the webcompat issue which exhibits the same issue, the OS is Linux
https://webcompat.com/issues/15406

I will create a test for someone to test on Edge/Windows.

for the pref
layout.word_select.eat_space_to_next_word;false

let's change that to true
layout.word_select.eat_space_to_next_word;true

It doesn't change anything to the behavior (on macOS)

Comment 10

[Mats Palmgren (inactive)]

(In reply to Karl Dubost :karlcow from comment #9)
> let's change that to true
> layout.word_select.eat_space_to_next_word;true
> 
> It doesn't change anything to the behavior (on macOS)

OK, thanks.

So, some quick testing in Firefox on OSX and Linux shows that
the problem occurs specifically for "word <br>".  It doesn't
occur on lines that end in space inside a <textarea> for example.
Weird.  I'm guessing it's unintentional.

As noted in comment 4 though, we need to be careful not to break
/that/ feature.

Seems like an edge case though, so not very high priority.

Comment 11

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 12

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 13

[Karl Dubost💡 :karlcow]

Probably something to add on this which could mitigate the issue. The double-selection visualization aka the colored box showing the selection is different than the real selected area. So that could indeed be confusing in terms of expectations.
I guess both should be fixed. The visualization and the default of double clicking on this type of strings.

Comment 14

[Mirko Brodesser -- away, unused old account]

Comparison of behavior on Chrome and Firefox on Windows for
data:text/html,<p>word X <br></p>

1. Double-click on the center of "word":
   Chrome: "word " selected and copied to clipboard.
   Microsoft Word: "word " selected and copied to clipboard.
   Microsoft Edge: "word " selected and copied to clipboard.
   Firefox: "word " selected and copied to clipboard.

2. Double-click on the center of "X":
   Chrome: "X" selected and copied to clipboard.
   Microsoft Word: "X " selected and copied to clipboard.
   Microsoft Edge: "X " selected and copied to clipboard.
   Firefox: "X " selected and copied to clipboard.

Comment 15

[Mirko Brodesser -- away, unused old account]

Comparison of behavior on Chrome and Firefox on Ubuntu for
data:text/html,<p>word X <br></p>

1. Double-click on the center of "word":
   Chrome: "word" selected and copied to clipboard.
   Firefox: "word" selected and copied to clipboard.
   gedit: "word" selected and copied to clipboard.
   Libre Office Writer: "word" selected and copied to clipboard.

2. Double-click on the center of "X":
   Chrome: "X" selected copied to clipboard.
   Firefox: "X " selected and " X " copied to clipboard (Yes, the first blank is copied).
   gedit: "X" selected and copied to clipboard.
   Libre Office Writer: "X" selected and copied to clipboard.

The behavior of using Ctrl+Arrow-left/Arrow-right differs for some use cases.
Moreover, the direction in which the language is written (left-to-right, e.g. for English, or right-to-left, e.g. for Arabic) might matter.

Comment 16

[Mirko Brodesser -- away, unused old account]

Given c15, at least case 2 should be fixed.

Comment 17

[Mirko Brodesser -- away, unused old account]

Results on OSX (thanks to Alphan):

1. Double-click on the center of "word":
   Chrome: "word " selected and copied to clipboard.
   Firefox: "word " selected and copied to clipboard.

2. Double-click on the center of "X":
   Chrome: "X" selected and copied to clipboard.
   Firefox: "X " selected and copied to clipboard.

Comment 18

[Mats Palmgren (inactive)]

(In reply to Mirko Brodesser (:mbrodesser) from comment #15)

Comparison of behavior on Chrome and Firefox on Ubuntu for
data:text/html,<p>word X <br></p>
2. Double-click on the center of "X":
Firefox: "X " selected and " X " copied to clipboard (Yes, the first blank is copied).

That's not what I'm seeing. My results in Nightly on Kubuntu (using a default profile):
Firefox: "X " selected and "X " copied to clipboard (no leading blank is copied).

I get the same result using the distro build (v74 "Mozilla Firefox for Ubuntu canonical 1.0")
with a default profile.

Comment 19

[Mirko Brodesser -- away, unused old account]

(In reply to Mats Palmgren (:mats) from comment #18)

(In reply to Mirko Brodesser (:mbrodesser) from comment #15)

Comparison of behavior on Chrome and Firefox on Ubuntu for
data:text/html,<p>word X <br></p>
2. Double-click on the center of "X":
Firefox: "X " selected and " X " copied to clipboard (Yes, the first blank is copied).

That's not what I'm seeing. My results in Nightly on Kubuntu (using a default profile):
Firefox: "X " selected and "X " copied to clipboard (no leading blank is copied).

I get the same result using the distro build (v74 "Mozilla Firefox for Ubuntu canonical 1.0")
with a default profile.

Right, thanks for pointing this out. I forgot to update the test-case for previous comments. With the following one, it should be reproducible:
data:text/html,<p>word X <br></p> (two whitespace characters before the "X").

Edit: oh, one whitespace was removed after pasting to this comment textarea.

Comment 20

[Mats Palmgren (inactive)]

OK, with two spaces I see the same result.

Comment 21

[Mirko Brodesser -- away, unused old account]

Given my limited knowledge of layout code, the problem seems to be around https://searchfox.org/mozilla-central/rev/c2bc259414706ef4be5d13df1344eebb7507a51b/layout/generic/nsFrame.cpp#4983,8779,8910 or perhaps ClusterIterator, which the former uses.