This is the fourteenth edition of the XUL/XBL Replacement Newsletter. Since the last edition, we’ve shipped browser.xhtml, started the process of removing the rest of the XUL documents in the tree, and continued to remove more XBL bindings.
As of this week the main browser window is no longer a XUL document. Also, the hidden XUL window (which is used on mac to provide menus when no browser window is visible) has been converted to XHTML. You (hopefully) didn’t notice this change in the UI but it’s the culmination of a lot of work, most notably by Brendan Dahl.
After we got the tree pretty much green with browser.xhtml (~75 bugs tracked mostly on the top-level html metabug and also detailed in newsletter #7), we began a performance investigation. We would have liked to have been able to load the browser window through the regular web-exposed HTML loading path, but investigation showed that getting to first paint in XHTML was slower than in XUL. Specifically, Talos performance tests showed regressions in tests that timed opening new browser windows or restoring the browser on startup.
The main reasons were that in XUL (1) we skip the XML parser in the “warm” startup case which Talos covers, and (2) we begin layout later, after the DOM is ready. We tried a bunch of workarounds for these. For example: making the document nearly empty and importing a shared fragment from JS, preventing early layout by hiding elements or suppressing it from Gecko, changing when various events fire in the document lifecycle. We would see incremental improvements with each approach, but nothing that reached the goal of parity with current performance, which is sensitive to even minor changes in the window opening time.
At the end of the investigation, we had learned enough about the
internals here that it seemed viable to expand prototype cache support
to XHTML documents as well. So the implementation was moved out of XULDocument
and into PrototypeDocumentParser
and PrototypeDocumentContentSink
. Thanks a lot to Smaug for the guidance and reviews in this process.
I still hold out hope that someday the normal loading path with a bit of tuning will be fast enough for our use-cases, but in the meantime this approach has a few nice benefits:
chrome://
XHTML document.XULDocument
implementation, which sets the stage for the rest of the XUL document burndown project - more on that below.What’s next? We are planning to migrate the root <xul:window>
element to <html>
, which will make the Browser Toolbox highlighters work like they do for web content. We’ll also rename the file
in tree from browser.xul to browser.xhtml: we were waiting to make sure
it stuck before doing any file moves since that can break in-flight
patches.
We are also starting on a plan to remove all XUL documents from mozilla-central. Based on feedback from a dev-platform post outlining the plan, we are going to adjust it to not focus as much on converting straight to .html and aim for .xhtml for most documents. See the post for more details but from a high level this looks like:
<xul:window>
-><html>
, convert ProcessingInstruction stylesheets to <link>
, etc. We’d like to automate this as much as possible since there are over 1500 xul documents in the tree.This work is being tracked in the following metabug.
There are 33 bindings left, compared to 44 from the last update and 300 from the start of the project. Here’s a list of changes:
button
and button-menu
bindings into a Custom Element.toolbarbutton
and toolbarbutton-badged
bindings into a Custom Element, which allowed us to remove button-base
in the process.label-control
into a Custom Element.
This also made accessKey formatting more consistent - the underlined
accessKey won’t get dropped anymore when textContent on an element is
updated, for instance.menuitem
, menuitem-iconic
, and menuitem-iconic-noaccel
bindings to a Custom Element, which allowed us to remove menuitem-base
in the process.search-textbox
to a Custom Element, and also started to break down work to convert plain textboxes to html:inputs.* The web page for revisions on the hg server doesn't show changes from before file moves (see: https://hg.mozilla.org/mozilla-central/log/tip/browser/base/content/browser.xhtml), but you can see those locally with the `-f` flag to hg log. So you can see all the history with `hg log -f browser/base/content/browser.xhtml`.