In bug 972485, we switched from using XHTML to XUL for about:customizing because it looked like aboutCustomizing.xhtml caused us to load bunch of MathML stuff via synchronous IO. This is particularly curious because aboutCustomizing.xhtml is a blank document, containing no MathML at all. We've switched from using XHTML to XUL, and the loads go away, but we really should be moving towards HTML and away from XUL - not the other way around. We should find out what happened here.

Should this be a Core bug? It seems like a bad web-perf issue, nevermind its impact on browser chrome.

Good question. Vladan - have you heard of this one before?

Did we ever actually confirm "slower to load"? All I see in bug 972485 was "XHTML causes main thread I/O", which is bad, but a different issue (http://hg.mozilla.org/mozilla-central/annotate/1238ef12b996/parser/htmlparser/src/nsExpatDriver.cpp#l264). I think we should just use plain old HTML, or if we need the l10n dtd, avoid also including the XHTML one that triggers the mathml weirdness.

(Or, as bug 975552 seems to be heading towards, just get rid of this page entirely! But a Core bug on file for the dtd issue is a good idea.)

(In reply to :Gavin Sharp (email gavin@gavinsharp.com) from comment #3) > Did we ever actually confirm "slower to load"? > > All I see in bug 972485 was "XHTML causes main thread I/O", which is bad, > but a different issue > (http://hg.mozilla.org/mozilla-central/annotate/1238ef12b996/parser/ > htmlparser/src/nsExpatDriver.cpp#l264). > > I think we should just use plain old HTML, or if we need the l10n dtd, avoid > also including the XHTML one that triggers the mathml weirdness. I think we should try with an HTML document to see what that buys us - but if it's not as good or better than preloading, I think that'd be the way to go. Note that it might even be possible to avoid creating a browser / docshell entirely. Loading about:customizing is mostly pointless - it's only necessary to give us a tab title and favicon. Dao suggested as much in https://bugzilla.mozilla.org/show_bug.cgi?id=975552#c3, and I'm trying to evaluate how difficult it'd be to pull off.

No, I've never heard of MathML delaying page load on blank pages. Can you link to aboutCustomizing.xhtml?

Sure: https://hg.mozilla.org/mozilla-central/file/20ae4f402369/browser/components/customizableui/content/aboutCustomizing.xhtml

I think we have this "figured out": - using some forms of xhtml does weird things with DTD loading - loading any page causes reflows that harm CART

Is there a bug for fixing the DTD issue?

This happens because you've explicitly asked for it to happen. Specifically it's because you have this in your .xhtml file: <!ENTITY % htmlDTD PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd"> %htmlDTD; That tells Expat (our XML parser) that you want to include the XHTML 1.0 Strict DTD. You're actually getting off lightly here because, since we don't use a validating XML parser, we only include the entities embedded by the DTD rather than the entire DTD itself. Specifically we load and embed all this: https://mxr.mozilla.org/mozilla-central/source/content/xml/content/src/htmlmathml-f.ent (Quite a lot of stuff.) Note that these entities need to be loaded before the parser can continue parsing since they may be used immediately after they're requested. To stop this from happening, just stop referencing the XHTML 1.0 Strict DTD. ;)

htmlmathml-f.ent, by the way, is the "combined HTML MathML entity set": http://www.w3.org/2003/entities/2007/htmlmathml.ent I'm not sure why we decided that's what we should load for XHTML 1.0 Strict (since that's not what the DTD for that version of XHTML embeds), but that's what we seem to embed for all known XHTML DTDs: https://mxr.mozilla.org/mozilla-central/source/parser/htmlparser/src/nsExpatDriver.cpp?rev=e6f113c83095#260

The inclusion of brand.dtd also seems like pointless overhead, since the only entity you reference is in browser.dtd.