When a mutation event such as DOMAttrModified, DOMNodeInserted or DOMNodeRemoved occurs somewhere inside an <a>, it is swallowed. I think this has something to do with the event ending up in nsGenericHTMLElement::HandleDOMEventForAnchors() and going no further.

joki is gone, -> me. Aaron, is this blocking anything?

Yes, but I'm not sure what the priority should be. It would be nice to get it fixed by January/February.

Now that the accessibility cache is implemented using mutation events, this is an important bug. If we don't fix it, the accessibility APIs could report incorrect data for some pages, and it would inevitably lead to crashes.

Other DOM events generated without a pres context would be swallowed by anchors as well.

Comment on attachment 124720 [details] [diff] [review] Shouldn't event get propogated up DOM tree even when aPresContext argument == nsnull? I'd suggest keeping the aEventStatus check as-is, and moving the aPresContext check like you suggested. However, I think it should be changed to an early return and not use NS_ENSURE_ARG (that macro implies and unexpected condition and spews to the console). I'm also curious why this event doesn't have an aPresContext parameter.

There's no pres context because the event is generated by the code in mozilla/content itself, for example nsGenericHTMLElement::SetAttr() or ::InsertChildAt()

Patch ready.

Comment on attachment 124799 [details] [diff] [review] New patch with bryner's suggestions sr=jst

this has been checked in