Incomplete MutationObserver records produced when merging an editable text node
Reported by
mari...@gmail.com,
Dec 7 2016
|
||||||||||
Issue description
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.100 Safari/537.36
Steps to reproduce the problem:
1. Create an editable paragraph like <p>foo<br>bar</p>
2. Register a MutationObserver on the editable node
3. With the cursor in front of the <br> node, press ctrl/cmd-delete
What is the expected behavior?
When the browser merges the text nodes before and after the <br>, a childNodes mutation record is produced telling me that the second text node ("bar") was removed.
What went wrong?
Only two records are produced, a childNodes record that tells me the <br> was removed, and a characerData record that tells me the text value of the first text node ("foo", now "foobar") was changed.
Did this work before? N/A
Does this work in other browsers? Yes
Chrome version: 54.0.2840.100 Channel: stable
OS Version:
Flash Version: Shockwave Flash 23.0 r0
,
Dec 13 2016
marijnh@Thanks for the issue. Could you please provide any test file or URL to triage the issue form test team end. Thanks,
,
Dec 13 2016
You can see it happen at http://marijnhaverbeke.nl/upload/test-mutations.html , though with current Chrome, ctrl-delete seems to delete the word after the BR node immediately, so you have to press plain delete to see the effect.
,
Dec 20 2016
Thank you for providing more feedback. Adding requester "kavvaru@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 21 2016
Tested on ubuntu 14.04 using latest stable 55.0.2883.87 and didn't observe difference in chrome and firefox results. Attached screenshot for reference. @marijnh-- Could you please check the attached screenshot and confirm us whether we have followed the steps correct. If possible provide us the screenshot of the expected result. Thanks!
,
Dec 21 2016
Firefox has the same issue. The problem with this behavior is that a change from the child list [textnode("foo"), BR, textnode("bar")] to [textnode("foobar")] is represented as a single childList record which removes the second child. But if you 'replay' that change, you'd end up [textnode("foo"), textnode("bar")], which is not the DOM structure that the document has. There's apparently some automatic joining of text nodes going on which is failing to fire the appropriate mutation records.
,
Dec 28 2016
Thank you for providing more feedback. Adding requester "hdodda@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 12 2017
@marijnh-- Could you please provide us the screencast to reproduce the issue , that would help us in investigating the issue further. Thanks!
,
Feb 11 2017
Text::mergeNextSiblingNodesIfPossible() uses setDataWitoutUpdate() then calls CharacterData::didModifyData() which put mutation record.
,
Oct 4 2017
,
Oct 4
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 4
Yes, this is still broken.
,
Oct 5
|
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by ranjitkan@chromium.org
, Dec 8 2016