New issue
Advanced search Search tips

Issue 909905 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Text selection may become invalid or out of range after an edit

Project Member Reported by sdy@chromium.org, Nov 28

Issue description

Chrome Version: 72.0.3624.0 (DCHECK will be added in crrev/c/1351530)
OS: 10.14.1 (18B75)

What steps will reproduce the problem?
(1) Load the following URI: data:text/html,<body contenteditable><ul><li>
(2) Click to place the insertion point at the first list item, then copy and paste the block of text in between the backticks (a letter 'a' followed by a newline — the newline is the important bit, not the character):

```
a

```

What is the expected result?
Nothing out of the ordinary happens.

What happens instead?
RenderWidgetHostViewMac::OnTextSelectionChanged is called with the string "a" and the range {2,2} (which points after the "a"). Currently this causes a crash on Touch Bar Macs (issue 893038), but after the above CL lands it will be a DCHECK instead. This probably isn't Mac-specific, it just only resulted in a crash on Mac. We got crash reports in the linked issue which include both invalid `gfx::Range`s and `gfx::Range`s which point outside the string; this just repros one flavor of the issue.
 
invalid_range_crash_demo.mp4
248 KB View Download
Status: Available (was: Untriaged)
The root cause is PlainTextRange::CreateRangeFor() returns wrong range.

The source of wrong range comes from RenderFrameImpl::SyncSelectionIfRequired() where
 text = "a" from WebLocalFrameImpl::RangeAsText()
 start = end = 2 from InputMethodController::GetSelectionOffsets()

The HTML is after paste of "a\n" is
  <div contenteditalbe><ul><li><li>a</li><li>|</li></li></ul>
where "|" is caret.

GetSelectOffsets() computes range from "a\n" ("\n" comes from </li>), then range is 2,2 (after "\n".

RangeAsText() uses PlainTextRange::CreateRangeFor() with "<div contenteditalbe>" and WebRange(0, 102) (102 = 2 (from GetSelectionOffsets() + 100 (== kExtraCharsBeforeAndAfterSelection)

Then PlainTextRange::CreateRangeFor() returns 0,1.


Note: this can be reproduceable with:
<ul contenteditable><li><li>a</li><li>|</li></li></ul>


Note that the DCHECK has been removed (my formerly-crashy code now just bails on getting an invalid range), but the bug remains.
Labels: -Stability-Crash

Sign in to add a comment