Make `HTMLEditor` handle `Selection` in replaced element and void element stricter
Categories
(Core :: DOM: Editor, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox148 | --- | fixed |
People
(Reporter: masayuki, Assigned: masayuki)
References
(Blocks 2 open bugs, Regressed 1 open bug)
Details
Attachments
(1 file)
Although it's non-realistic edge cases though, we should handle the cases stricter than now. E.g., we do special handling only for <select> in some cases.
|
Assignee | |
Comment 1•28 days ago
|
||
Currently, we do something special only for <select>, <option>
and <optgroup>. However, we should treat replaced elements and
void elements more consistently.
This patch adds new HTMLEditUtils methods to check them easier and
stricter and get the root node of them because DOM API can make invalid
tree even in a void element.
Then, we should handle insertions before the replaced or the void
element if selection range is collapsed in it. However, deletion should
not be handled for that if the range is completely in such element.
Additionally, if range boundary is in such element, we should adjust
the range not to include such element since it's not fully selected
so that shouldn't be deleted nor replaced. These rules are basically
compatible with Chrome.
Finally, if such element is completely hidden, such elements should be
deleted silently with deleting surrounding content if collapsed next to
one. However, this does not work well with a Backspace key press even
after applying this patch.
Finally, some tests of editing-around-select-element.tentative.html
start failing. The reason is, this patch makes the surrounding block
boundary of <select> with adjusting the selection range and that makes
<select> moved into another parent. At this time, the <select>
gets style="white-space: nowrap". I'm not sure where did this but
not a critical failures. Therefore, this patch contains this
regression.
Description
•