MutationObserver does not report the nodes of a line as added or removed when those nodes are deleted into the previous line
Categories
(Core :: DOM: Editor, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox115 | --- | fixed |
People
(Reporter: briankimpossible, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
|
(deleted),
text/html
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
Steps to reproduce:
Open the attached mutationobserverbug.html file.
mutationobserverbug.html
<!DOCTYPE html>
<html>
<body>
<pre id="editable" contenteditable="true"><div>Line 1</div><div><span>Line 2</span></div></pre>
<script type="module">
const observer = new MutationObserver((records) => {
console.log(records);
});
observer.observe(document.getElementById("editable"), {
subtree: true,
childList: true,
characterData: true,
});
</script>
</body>
</html>
Put the cursor at the start of the second line and press backspace.
Open the console.
One of the mutation records should have the span which was merged into the previous line in their addedNodes or removedNodes.
Actual results:
When attaching a MutationObserver to a contenteditable element, DOM elements which are merged into a previous line do not show up in any of the mutation records generated for the change. The line which was deleted does not contain any of its original contents, and the DOM nodes are not mentioned in any addedNodes or removedNodes list of any other mutation. In the example, this second line is missing a span but it appears magically in the first line without actually being reported as a mutation.
Expected results:
The span should be reported as having been added to the first line, and removed from the second line.
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Editor' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Looking at the mutation records, it's not that the second line merges to the first line, instead the first line merges to the second one. The text node of the first line is removed from the first div, then added to the second div, and then the first div detaches. <span> is never reported because it indeed never moves.
Since the contenteditable spec does not require any specific behavior, I don't think this is a bug. But probably good idea to cross check with Masayuki:
Looking at the mutation records, it's not that the second line merges to the first line, instead the first line merges to the second one. The text node of the first line is removed from the first div, then added to the second div, and then the first div detaches. <span> is never reported because it indeed never moves.
Since the contenteditable spec does not require any specific behavior, I don't think this is a bug. But probably good idea to cross check with Masayuki:
Yes, you are indeed correct. My confusion was based on the fact that Safari and Chrome both seem to merge the second line into the first line when merging text backwards, while Firefox will merge the first line into the second. I’m not sure either behavior is incorrect, though I find Safari/Chrome’s behavior to be slightly more intuitive given that we’re deleting backwards. Nevertheless, it revealed a critical bug in my text editor implementation so I have Firefox to thank for that.
|
||
Comment 4•3 years ago
|
||
Thank you for your investigation, Kagami. It sounds like that this is a variation of bug 1449874. I guess that fixing this may be hard because if we forget to change somewhere doing same things, it breaks undo/redo. So, there is a risk of dataloss.
|
|
||
Updated•3 years ago
|
Yes, the original <span> is now in the joined paragraph.
|
||
Updated•1 year ago
|
|
|
||
Updated•1 year ago
|
Description
•