selecting text via 'ctrl/cmd' > 'a' and deleting contenteditable content also deletes <p> element. Other browsers (other than IE11) do not.
Categories
(Core :: DOM: Editor, defect, P3)
Tracking
()
People
(Reporter: thecrookster, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: parity-chrome, parity-edge, Whiteboard: [h2review-noted])
Attachments
(2 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Steps to reproduce:
Here's a test snippit:
<html>
<div class="note-editable" contenteditable="true"><span class="textFitted responsiveColor responsiveFontSize responsiveFontFamily" style="overflow-wrap: normal; font-size: 79px;"><p>Select this and click delete. The P node will disappear<br></p></span></div>
</html>
Open the snippit in Firefox (60.4.0esr 64bit), select the text (ctrl/cmd > a) and press delete
Actual results:
The <p> node is deleted
Expected results:
The <p> node remains
|
||
Updated•6 years ago
|
|
|
||
Comment 1•6 years ago
|
||
|
|
||
Updated•6 years ago
|
|
|
||
Comment 2•6 years ago
|
||
span and p remain in Edge and Chrome.
nothing remains in Firefox.
|
||
Comment 3•6 years ago
|
||
It seems the root of the problem is that Chrome does something
different for CTRL+A. It doesn't select all content as one
would expect but just wraps the text. Then it "compensates"
for that by also deleting the ancestors (if they became empty
presumably) but makes an exception for P for some reason.
|
|
||
Comment 4•6 years ago
|
||
I tend to think this is a bug in Chrome. That behavior seems
quite baroque to me and I don't think we should implement it.
|
Reporter | |
Comment 5•6 years ago
|
||
The only other browser that acts like FireFox is IE11. Safari, Opera, Edge, and Chrome all retain the <p>. And perhaps IE11 acts that way is because it's not supported anymore and is essentially a dead browser. So, if you do not implement this, Firefox is the only current browser that exhibits this behaviour. Baroque or not.... it is the standard it seems and I feel Firefox should act... standard. Thx. Shawn
|
||
Updated•6 years ago
|
|
|
||
Updated•6 years ago
|
|
||
Comment 6•5 years ago
|
||
Guys,
What is different is the way that the selection object and range object work. Webkit (before the blink fork) changed the behaviour so that they are set to the content that would be visible and Microsoft followed suit. So, in this this case, the range and selection object selections become the children of the p element rather than the p element which leads to desirable behaviour deleting content as well as merging content where a number of similar problems also exist for the same reason. I can't begin to tell you how much code I written to avoid these types of issues that could just go away if we followed the same behaviour and created a standard.
If you think about it Mozilla is all about creating standards and a better environment for everyone. I say lets come together and create a standard rather than create fragmentation and division.
Cheers,
Alex
|
||
Updated•4 years ago
|
|
||
Updated•2 years ago
|
Description
•