At the moment dispatching DOMAttrModified is implemented in 6 places, twice in GenericElement, twice in XULElement and once in HTMLElement and SVGElement. There could be one (or perhaps two, REMOVAL may need its own) static method in nsGenericElement to implement it once and properly. Bug 231676 is another solution for this, but it needs changes to document observer.
Created attachment 168983 [details] [diff] [review] v1 This adds (static) nsGenericElement::DispatchDOMAttrModified. It is used in every place, where DOMAttrModied is created. This also fixes few bugs. REMOVAL is now dispatched after the attribute has been removed and the relatedNode is the correct nsIDOMAttr - now also the namespaced attributes should work.
Attachment #168512 - Attachment is obsolete: true
As Jonas said in Bug 232009 "Currently the attribute-node can be compleatly unaware that it no longer is an attribute on the element." Have to fix that too, but it is probably separate bug.
Status: NEW → ASSIGNED
The absolutly best solution would be to fix bug 231676. However this is a step in the right direction.
Should the patch be reviewed?
(In reply to comment #5) > Should the patch be reviewed? > Ah, no. This is old. Way too old.
13 years ago
Attachment #168983 - Attachment is obsolete: true
At this point we're down to three dispatchers of DOMAttrModified: nsXULElement::UnsetAttr nsGenericElement::SetAttrAndNotify nsGenericElement::UnsetAttr I believe we wanted to merge the latter two by having an AfterSetAttr method or something. At least sicking's mentioned something like that. nsXULElement::UnsetAttr should just call up into the superclass more somehow.
this was fixed long ago.
Assignee: bugs → nobody
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.