Open Bug 1294197 Opened 4 years ago Updated 2 years ago

Make Mutation Observer report parser mutations in XUL

Categories

(Core :: XUL, defect, P5)

defect

Tracking

()

People

(Reporter: zbraniecki, Unassigned)

Details

Attachments

(2 files, 2 obsolete files)

It currently seems that for XUL we do not report mutations that come from the parser.

The simple test I did:

<?xml version="1.0"?>

<window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">

<script type="application/javascript">
const target = document.documentElement;

const observer = new MutationObserver((mutations) => {
  console.log('onMutations');
  console.log(mutations);
});

const observerConfig = {
  attributes: true,
  characterData: false,
  childList: true,
  subtree: true,
};

observer.observe(target, observerConfig);

let x = document.createElement('label');
x.textContent = 'Foo2';

document.documentElement.appendChild(x);
</script>
  <label>Foo</label>
</window>


and the Mutations are reported for 'Foo2', but not for 'Foo'.

We'd like to rely on MO behavior for L20n in Firefox and for that we need to be able to catch elements with data-l10n-id as they're inserted into DOM and translate them in MutationObserver callback.
Attached patch aboutDialog.diff (obsolete) — Splinter Review
Steps to Reproduce:

1) Apply this patch on m-c
2) ./mach build browser/base
3) ./mach run
4) open "chrome://browser/content/aboutDialog.xul"
Attached patch aboutDialog.diff (obsolete) — Splinter Review
update STR patch to make it work against m-i
Attachment #8779832 - Attachment is obsolete: true
mozbuild.preprocessor.Error: ('/home/smaug/mozilla/hg/inbound2/browser/base/content/aboutDialog.xul', None, 'no preprocessor directives found', None)
Attached patch aboutDialog.diffSplinter Review
Attachment #8779839 - Attachment is obsolete: true
Attached patch wipSplinter Review
remote:   https://treeherder.mozilla.org/#/jobs?repo=try&revision=431936b963c7
remote: 
remote: It looks like this try push has talos jobs. Compare performance against a baseline revision:
remote:   https://treeherder.mozilla.org/perf.html#/comparechooser?newProject=try&newRevision=431936b963c7
I know it's a WIP, but I decided to give it a try.

One thing I noticed is that it seems it serves one MutationRecord for each and every node added separately, while in the HTML scenario it clusters all nodes served by parser together into a couple MutationRecords.

In result, when I plugged MutationObserver into browser.xul, I got onMutations called 10 times, but the first of them had 1105 MutationRecords, each with one "addedNode".

That means that iterating over those 1150 records to get 1150 addedNodes is fairly costly.
Is it possible to optimize that?
Flags: needinfo?(bugs)
not without changing how we construct xul documents.
Flags: needinfo?(bugs)
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.