If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Parsing directly to context node mutation event faking inconsistent with equivalent DocumentFragment insertion after bug 650493

NEW
Assigned to

Status

()

Core
DOM
6 years ago
3 years ago

People

(Reporter: hsivonen, Assigned: sicking)

Tracking

({regression})

Trunk
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox8-)

Details

(Reporter)

Description

6 years ago
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.

Updated

6 years ago
Assignee: nobody → jonas

Comment 1

6 years ago
We should probably fix this regression sooner than later.

(It seems that the mutation event replacement takes still time.)
tracking-firefox8: --- → ?
Keywords: regression

Comment 2

6 years ago
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!
tracking-firefox8: ? → -

Comment 5

6 years ago
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.
(Reporter)

Comment 6

6 years ago
(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.

Comment 7

6 years ago
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.
You need to log in before you can comment on or make changes to this bug.