Closed Bug 1665944 Opened 4 years ago Closed 3 years ago

Multi-paragraph text selection is broken on Notion

Categories

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

defect

Tracking

()

VERIFIED FIXED
86 Branch
Tracking Status
firefox86 --- verified

People

(Reporter: saschanaz, Assigned: saschanaz)

Details

Attachments

(2 files)

  1. Open https://www.notion.so/The-Beauty-of-Notion-4663b221fd154c07bb6f826b537bfcd4
  2. 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.

Flags: needinfo?(krosylight)
Attached file notion-repro.html

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.

Flags: needinfo?(krosylight)
Assignee: nobody → krosylight
Severity: -- → S3
Priority: -- → P2

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.

So,

  1. the event dispatcher fires events from the text frame
  2. which calls mousemove event listener
  3. where textarea.select() sets the focus/anchor offset to the position before textarea
  4. then the event dispatcher proceeds to nsIFrame::HandleEvent which leads to nsFrameSelection::HandleDrag, still with the original text frame
  5. which sets the focus offset to the text node offset below the mouse cursor
  6. 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?

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.

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.

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
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 86 Branch
Upstream PR merged by moz-wptsync-bot
Flags: qe-verify+

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.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: