Double click to highlight word doesn't highlight first word when cursor is moved left then right
Categories
(Core :: Layout: Text and Fonts, defect, P3)
Tracking
()
People
(Reporter: 99jackpearson, Assigned: jfkthame)
References
(Regression, )
Details
(Keywords: parity-chrome, regression)
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0
Steps to reproduce:
- Navigate to a webpage with plain text (say, https://en.wikipedia.org/wiki/Mozilla).
- Double click on a word (say, "founded")
- Hold mouse after second click to continue selecting words
- Move cursor one word left ("community")
- Return cursor to original word
Actual results:
The left word ("community") was not highlighted, and the original word ("founded") also was not highlighted.
Expected results:
The left word ("community") was not highlighted, but the original word ("founded") was highlighted.
![]() |
||
Comment 1•5 years ago
|
||
Steps to reproduce:
- open data:text/html,<h1>prev%20this%20next</h1>
- Double click on word "this". And do not release mouse button
- Move mouse pointer to "prev".
- And then move to "this"
- Optionally, continue move to "next"
Actual Results:
At step 2: "this " is selected
At step 3: "prev this " is selected
At step 4: nothing is selected --- bug
At step 5: "next" is selected --- bug
Expected Results:
At step 2: "this " is selected
At step 3: "prev this " is selected
At step 4: "this " is selected
At step 5: "this next" is selected
Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=80eefd4207ce&tochange=0322169bc93e
Comment 2•5 years ago
|
||
I can confirm this happens on OS X, as well.
Comment 3•5 years ago
|
||
The commits for https://bugzilla.mozilla.org/show_bug.cgi?id=371839 seem a likely cause, given the regression window.
Assignee | ||
Comment 4•5 years ago
|
||
It looks to me like it's running into some kind of confusion regarding the anchor vs focus ends of the selection range, such that the selection incorrectly collapses to the end of the originally-doubleclicked word.
Note that if we continue from the STR in comment 1 with
- Continue moving mouse back into "this"
the selection becomes correct again.
Assignee | ||
Comment 5•5 years ago
|
||
This also affects selecting with a triple-click (to select a whole paragraph) and drag:
Testcase:
data:text/html,<p>first line<p>second line<p>third line
Triple-click in "second line" to select it; then drag upwards into "first line" to extend the selection; then back down into "second line". Expected: "second line" is selected. Actual result: no selection.
The issue arises because the selection code mishandles the anchor/focus ends of the "maintained range" representing the originally-clicked word (or line). When initially double-clicked, we save the range, with its anchor at the start and focus at the end. When dragging leftwards to the preceding word, we need to swap the ends of the maintained range so that the anchor will be at its end, and the selection will extend to the focus that is being updated as we drag. This much works fine.
However, when the mouse is dragged back into the original word, the anchor of the maintained range is now at its end, and the dynamically-moving focus also jumps to the end of the word, and we end up with an empty selection. To avoid this, when the mouse re-enters the maintained range, its anchor and focus ends need to revert to the original order.
Assignee | ||
Comment 6•5 years ago
|
||
Updated•5 years ago
|
Assignee | ||
Comment 7•5 years ago
|
||
Depends on D78545
Comment 9•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/ee15802eedda
https://hg.mozilla.org/mozilla-central/rev/d0b8c9d1e237
Updated•5 years ago
|
Description
•