| Summary: | <hr> cannot be selected within a contenteditable | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Kenneth Lim <kenlimmj+webkit> | ||||
| Component: | HTML Editing | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | NEW --- | ||||||
| Severity: | Normal | CC: | megan_gardner, rniwa, webkit-bug-importer, wenson_hsieh | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | Safari 13 | ||||||
| Hardware: | Mac | ||||||
| OS: | macOS 10.15 | ||||||
| Attachments: |
|
||||||
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>```