It appears that the fix for bug 650493 caused the faked mutation events for the case where the HTML parser parses directly into a context node in innerHTML setter or insertAdjacentHTML to differ from the mutation events that are emitted if the parser parses into a DocumentFragment and the fragment is then inserted. Steps to reproduce: 1) Restore the insertAdjacentHTML tests to a state that corresponds to attachment 524158 [details] [diff] [review] 2) Run the tests 3) Remove the direct-to-context-node path from the insertAdjacentHTML implementantion 4) Run the tests again Actual results: The tests fail when parsing directly into the context node. Expected results: Expected the same mutation events with or without the direct-to-context-node optimization. Additional info: Things were OK before bug 650493 landed.

We should probably fix this regression sooner than later. (It seems that the mutation event replacement takes still time.)

We don't know how to evaluate this because we don't understand the scope of possible web breakage. Please give us more.

I'd love help here. I don't actually think this is a big deal though as the order of mutation events have never been defined and I strongly suspect that they vary between implementations. I guess I don't see that much value in making our mutation events implementation perfect given that it should get deprecated anyway. Of course, if we see actual site breakage because of this then that will change the priority.

We discussed this in triage today - all for fixing this, but it's not Firefox-8-specific -> tracking-. If there's a safe patch to nominate for approval, we'll have a look!

Hi, any updates for this bug? I can't point to be site breakage and I would highly like the behavior to be the same as I rely on it in my extension. For now any known workarounds will be acceptable too. Thanks.

(In reply to Sunil from comment #5) > Hi, any updates for this bug? I can't point to be site breakage and I would > highly like the behavior to be the same as I rely on it in my extension. Please don't listen to mutation events on Web pages from an extension. It makes Firefox slow.

Thanks Henri for suggestions. This extension is not to be released for general public consumption but to be used in a limited environment. I understand the performance issue. On the other hand, I'm fine observing nsIMutationObserver/nsIMutationObserver2, however it's not available to Javascript plugins. Is there a quick/easy way to write a C++ plugin that would allow JS plugins to observer those mutations? I understand nsIMutationObserver doesn't have the same performance penalty.