Open Bug 1043118 Opened 7 years ago Updated 6 months ago

Do not select leading/trailing spaces on double clicking.

Categories

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

defect

Tracking

()

Webcompat Priority P3
Tracking Status
firefox71 --- affected
firefox72 --- affected
firefox73 --- affected

People

(Reporter: hiro, Unassigned, NeedInfo)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [webcompat])

Attachments

(1 file)

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

<p>word  <br></p>
Attached patch bug1043118Splinter Review
Attachment #8461283 - Flags: review?(roc)
Blocks: 437679
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
-    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.)
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 */
Flags: needinfo?(hikezoe)
Flags: needinfo?(bzbarsky)
Whiteboard: [webcompat]
Flags: webcompat?
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....
Flags: needinfo?(bzbarsky)
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.
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?
Flags: needinfo?(kdubost)
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)
Flags: needinfo?(kdubost)
(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.
Severity: normal → minor
Priority: -- → P3
Flags: webcompat?

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

Webcompat Priority: --- → ?

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

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.

Summary: Do not select trailing spaces on double clicking. → Do not select leading/trailing spaces on double clicking.
Flags: needinfo?(mbrodesser)
Flags: needinfo?(mbrodesser)
See Also: → 639579

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.

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.

Given c15, at least case 2 should be fixed.

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.

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

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

OK, with two spaces I see the same result.

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.

Blocks: 1633247
Webcompat Priority: ? → P3
You need to log in before you can comment on or make changes to this bug.