1369575 - XUL_URL use in ExtensionParent.jsm and ExtensionXPCShellUtils.jsm is misleading since it's only half XUL

Status: RESOLVED INVALID

(WebExtensions :: General, defect, P5)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

toolkit/components/extensions/ExtensionXPCShellUtils.jsm and toolkit/components/extensions/ExtensionParent.jsm both have code that loads a data: URL called XUL_URL, which is:

data:application/vnd.mozilla.xul+xml;charset=utf-8,%3C?xml%20version=%221.0%22?%3E%0A%20%20%3Cwindow%20id=%22documentElement%22/%3E

This was added in https://hg.mozilla.org/mozilla-central/rev/f55699ce1dbd (but has since moved around).

What this does it it kicks off a document load using the XULContentSink, creates a XULDocument, creates a generic nsXMLElement since the root element has no namespace, and then performs regular CSS block layout (not XUL layout) on it.

It seems a little misleading to call that XUL_URL.

On the other hand, the less XUL the better.  Is there a reason this can't just be all HTML?


(I noticed this because I was looking at reflows that happen during startup.  We reflow this document twice, first under the initial assumption that it will have scrollbars, and then again because it turns out not to.)

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: stack of root element creation

Comment 2

[Kris Maglione [:kmag]]

We initially used an HTML document for this, but when we did, we never got any layout at all, so the <browser> that we injected never wound up with a SubdocumentFrame, and their child docshells didn't inherit a PresShell. They also didn't support remote frameLoaders, as I recall.

Comment 3

[Rob Wu [:robwu]]

There is no XUL_URL in those files any more.

It was replaced with dummy.xul in https://searchfox.org/mozilla-central/diff/52592be689d4ff73d8b820fe5027681a0dbf11c4/toolkit/components/extensions/ExtensionParent.jsm#838
and later replaced with dummy.xhtml