Multi-paragraph text selection is broken on Notion
Categories
(Core :: DOM: Selection, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox86 | --- | verified |
People
(Reporter: saschanaz, Assigned: saschanaz)
Details
Attachments
(2 files)
- Open https://www.notion.so/The-Beauty-of-Notion-4663b221fd154c07bb6f826b537bfcd4
- Select multiple paragraphs by dragging from inside the paragraph (not from outside of it)
Expected: Custom selection indicator should appear
Actual: It appears but unexpectedly the selection extends to the bottom of the document.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
•
|
||
Got a minimal repro.
Notion calls textarea.select()
while extending selection by mouse and this causes malfunction in Gecko. Blink cancels existing selection limits the selection inside textarea when this occurs, and we should probably also follow them.
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 2•4 years ago
|
||
Intermediate report: I found that PresShell::SetCapturingContent
somehow prevents further selection change but it somehow does not prevent the initial selection change (which causes selecting all nodes between cursor and the textarea
). Selection::RemoveAllRange
helps but it causes behavior change with regression. I think the solution here doesn't need such behavior change, so I'll keep finding a way to prevent the initial selection change.
Assignee | ||
Comment 3•4 years ago
•
|
||
So,
- the event dispatcher fires events from the text frame
- which calls mousemove event listener
- where
textarea.select()
sets the focus/anchor offset to the position before textarea - then the event dispatcher proceeds to nsIFrame::HandleEvent which leads to nsFrameSelection::HandleDrag, still with the original text frame
- which sets the focus offset to the text node offset below the mouse cursor
- and thus the weird selection
We would need to make select() to prevent step 4 and 5 to fix the Notion bug inside Gecko. Adding PresShell::SetCapturingContent
inside select()
is not helpful as event dispatching will still proceed with the same frame.
But then, is it really expected for textarea.select()
to cancel/redirect the text-selecting user action? Is the current Gecko behavior really wrong?
Assignee | ||
Comment 4•4 years ago
•
|
||
It turns out that the same happens with textarea.focus()
, while it does not if focusing element is a contenteditable. Which implies there should be an existing way to prevent this.
Assignee | ||
Comment 5•3 years ago
•
|
||
The behavior changes when adding a contenteditable node anywhere in the document. 🤔🤔 Investigating again...
Edit: The selection root becomes the textarea element with a contenteditable sibling, while it's the internal child div when without a contenteditable sibling.
Assignee | ||
Comment 6•3 years ago
|
||
Pushed by krosylight@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/04e48d1c7a4c Unset drag state when moving focus to text controls r=emilio
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/27119 for changes under testing/web-platform/tests
Comment 9•3 years ago
|
||
bugherder |
Upstream PR merged by moz-wptsync-bot
Updated•3 years ago
|
Comment 11•3 years ago
|
||
Confirmed issue with 82.0a1 (2020-09-18) on macOS 11.0.1.
With the attached test case -86.0b5:
- While on the reported site, it appears to work ok.;
- there is an improvement from with bad builds. Selection still jumps on all other browsers.
Description
•