Bug 93787
| Summary: | DOMCharacterDataModified incorrectly firing for innerHTML changes | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Jon <jonnew> |
| Component: | DOM | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | abarth, ahmad.saleem792, ap, bfulgham, jeffrey+webkit, rniwa |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://jsfiddle.net/newtang/kysTm/15/ | ||
Jon
To reproduce:
1. Have a node that contains only text. Add a DOMCharacterDataModified event listener
2. Change the node's contents using innerHTML
What is the expected result?
DOMCharacterDataModified does not fire. The W3 spec (http://www.w3.org/TR/DOM-Level-2-Events/events.html) says, "Fired after CharacterData within a node has been modified but the node itself has not been inserted or deleted." I didn't think innerHTML would adjust the existing textNode; I thought it would replace it with a completely different node.
What happens instead?
DOMCharacterDataModified does fire.
I made this jsFiddle to demonstrate: http://jsfiddle.net/newtang/kysTm/15/
and created this StackOverflow question:
http://stackoverflow.com/questions/6528511/domcharacterdatamodified-not-firing-consistently-across-firefox-and-chrome-who-i
It appears that Firefox is handling this situation correctly, but ultimately, I'm more interested in consistency across the browsers.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Lucas Forschler
Mass move bugs into the DOM component.
Ahmad Saleem
Following is output of all browsers:
*** Safari 15.6 on macOS 12.5 ***
DOMSubtreeModified
DOMNodeInserted
DOMSubtreeModified
*** Chrome Canary 106 ***
DOMSubtreeModified
DOMNodeInserted
DOMSubtreeModified
*** Firefox Nightly 105 ***
DOMNodeInserted
_________
I am not clear on web-spec but this is output across all browsers, please mark this bug according. If it is bug and Firefox behavior is aligned with web-spec then it can be changed to "New" status but if Safari is correct then it can be marked as "RESOLVED CONFIGURATION CHANGED" or something. Thanks!
Ahmad Saleem
Further the test case from StackOverflow:
Link - https://jsfiddle.net/doktormolle/yQu8v/
It shows same across all browsers:
DOMCharacterDataModified
DOMSubtreeModified
Ryosuke Niwa
*** This bug has been marked as a duplicate of bug 18169 ***