Bug 213039 - <hr> cannot be selected within a contenteditable
Summary: <hr> cannot be selected within a contenteditable
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: Safari 13
Hardware: Mac macOS 10.15
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-06-10 11:55 PDT by Kenneth Lim
Modified: 2020-06-11 18:13 PDT (History)
4 users (show)

See Also:


Attachments
Minimum repro case of a <hr> inside a <p> element in a contenteditable (117 bytes, text/html)
2020-06-10 11:55 PDT, Kenneth Lim
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kenneth Lim 2020-06-10 11:55:34 PDT
Created attachment 401563 [details]
Minimum repro case of a <hr> inside a <p> element in a contenteditable

See attached min. repro. When a `<hr>` element is placed inside a `<p>` element, it is hoisted out of the encapsulating element, and it does not seem to be possible to make a selection over the `<hr>` element in the content editable.

Steps to reproduce:

1. Place the caret at the end of "Paragraph 1"
2. Keyboard navigate over to "Paragraph 2" (right arrow key a few times in a LTR context)

Actual Results:

Cursor first moves to an empty `<p>` element, skips over the `<hr>` element, then moves to a second `<p>` element, before ending up at "Paragraph 2".

The `<hr>` element that was originally encapsulated in the `<p>` element is now hoisted out to become:

```
<p></p>
<hr>
<p></p>
```

Note this hoisting appears to happen regardless of whether everything is inside a contenteditable.

Expected Results:

Cursor should move to before the `<hr>` element, then after, i.e. offset 0 within the encapsulating `<p>` element, followed by offset 1 within the same `<p>` element.

The `<hr>` element should remain wrapped inside the `<p>` element, i.e.

```<p><hr></p>```
Comment 1 Radar WebKit Bug Importer 2020-06-11 18:13:29 PDT
<rdar://problem/64278952>