XUL/XBL Replacement Newsletter 20

This is the twentieth edition of the XUL/XBL Replacement Newsletter. As of last week, we have 0 xul files in mozilla-central. We’ve also been scoping out the work remaining in "XUL Replacement", and have an update on post-XBL cleanups.

No more XUL files in mozilla-central

Back in May, I posted an outline of a plan to remove all XUL documents from mozilla-central to dev-platform. Based on feedback, we adjusted the plan to be smaller in scope and focused on (1) loading all XUL files as if they were HTML and (2) renaming .xul files to .xhtml. The first step was completed by Brendan Dahl in July (see newsletter #16), and Emma Malysz started on the second in October (see newsletter #18).

Emma did a great job breaking down and renaming the ~1500 files. It’s been split up primarily by directory using a script to handle the simpler test file renames, and manually handling the more complicated cases like files loaded over chrome://. This has led to a really nice burndown of xul files in mozilla-central, hitting 0 on Friday.

Another nice result of this project is that eslint operates on .xhtml files but not .xul, so we have increased lint coverage across the tree. Mark Banner also recently improved this support by handling self closing script tags in xhtml files.

XUL document burndown chart, starting with around 1400 documents on 2019-10-02 and ending with 0 documents on 2019-12-13

What’s left to do?

Over the last 2 years, we’ve accomplished a lot in this program. We’ve removed XUL Templates, XUL Overlays, XBL Stylesheets, XUL Documents, XBL, and converted all XUL files to XHTML - migrating to web technologies when possible. So what's left to do? The three remaining projects we're tracking are:

  1. Complete the DTD conversion to Fluent.
  2. Remove the XUL flex model and the other XUL layout frames.
  3. Migrate XULElements that have a web equivalent to HTMLElement.

The work in (1) is well scoped and you can expect to see more updates about it early next year. For (2) we’ve been making progress on removing XUL layout frames like stack, grid, and groupbox but still have some performance issues with flexbox along with some functional issues that will be helped by doing (3). So I’d like to talk about more about (3) here.

First, I expect that we will still ship a number of XULElements even after we complete this program. I’ve talked about this before, but things like panel, browser, the menu elements (menu, menupopup, menucaption, menuitem, menulist) don’t have HTML equivalents and are important for our desktop browser experience. While we could invent a way to do this in chrome HTML, I don’t think the cost/benefit justifies doing that ahead of the rest of the things in our list.

So that leaves more "vanilla" XUL elements that are primarily implemented in JS. These cover the majority of our UI and are things like hbox, button, textbox, tab, richlistbox, etc. There are a couple of hurdles here:

a) XULElements act differently from HTMLElements in some ways. For example, getAttribute("not-existent") returns null in HTML and "" in XUL. XUL has some "magic attributes" that dictate layout and other behavior. And XUL supports features like [command] & [tooltip] which don’t have an equivalent in HTML. b) There’s a long tail of UI migrations that need to happen. These include changing the base Custom Element classes and also updating markup / CSS to use the new element name / namespace.

We're thinking it makes sense to work on (a) tree-wide first (metabug), and treat (b) as a separate project (metabug). The reason to treat these separately is so that we don’t need to repeat the subset of changes needed for (a) for every single element in (b). In other words, we’d like (b) to be able to be as automated as possible, and selectively rewriting how frontend JS interacts with elements would be a roadblock to doing so.

More XBL cleanup

There have been some really nice simplifications and code removals happening in the remove-xbl-implementation metabug. Lines of code isn’t the best measurement for this type of simplification, but for what it’s worth there's been a net removal of around 24K LOC so far.