Dispatching Mutation Event DOMAttrModified is implemented in several places

RESOLVED FIXED

Status

()

RESOLVED FIXED
14 years ago
5 years ago

People

(Reporter: smaug, Unassigned)

Tracking

(Depends on: 1 bug)

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 obsolete attachments)

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.
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.
The merging comment 7 mentions is bug 314286.
Depends on: 314286
QA Contact: ian → events
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.