Open Bug 1043118 Opened 7 years ago Updated 6 months ago
Do not select leading/trailing spaces on double clicking
Word selection on double clicking selects extra spaces in particular HTML codes like this: <p>word <br></p>
Attachment #8461283 - Flags: review?(roc) → review+
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 */
See Also: → https://webcompat.com/issues/15406
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....
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?
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)
(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
Webcompat Priority: --- → ?
See Also: → 639579
You need to log in before you can comment on or make changes to this bug.