XUL/XBL Replacement Newsletter 14

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.

Shipping browser.xhtml

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:

  • The faster path is now enabled automatically for any chrome:// XHTML document.
  • It nearly emptied out what was left of the XULDocument implementation, which sets the stage for the rest of the XUL document burndown project - more on that below.
  • We could expand support to other chrome document types if we’d like (for instance, SVG).

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.

XUL document burndown

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:

  1. Load all XUL documents as XHTML using the prototype cache. This doesn’t require any file renaming, we will just detect a .xul file and act like it’s .xhtml. This is tracked in Bug 1550801
  2. Delete the XULDocument implementation.
  3. For most files, rename .xul->.xhtml. In this case everything should work identically with the file name changed since it’s already being loaded as such with (1). The main extra task here is to update bug, code, and comments referencing the old file name
  4. For the now-xhtml documents apply cleanups when appropriate. For instance, migrate <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.

Binding Removals

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: