XUL/XBL Replacement Newsletter #20

Brian Grinstead bgrinstead at mozilla.com
Mon Dec 16 18:01:15 UTC 2019


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 <https://groups.google.com/forum/#!msg/mozilla.dev.platform/LXsSeAnJpbc/Z4x8i605AgAJ> 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 <https://bugzilla.mozilla.org/show_bug.cgi?id=1550801> and (2) renaming .xul files to .xhtml <https://bugzilla.mozilla.org/show_bug.cgi?id=1579952>. The first step was completed by Brendan Dahl in July (see newsletter #16 <https://groups.google.com/d/msg/firefox-dev/WGcGYaQgu3g/-Z5jtoWdEAAJ>), and Emma Malysz started on the second in October (see newsletter #18 <https://groups.google.com/d/msg/firefox-dev/9zV1Th5vcCA/9minfl_8CQAJ>).

Emma did a great job breaking down and renaming the ~1500 files. It’s been split up primarily by directory using a script <https://bug1579952.bmoattachments.org/attachment.cgi?id=9100360> 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 <https://bgrins.github.io/xul-document-burndown/>, hitting 0 on Friday.

Another nice result of this project is that eslint operates on .xhtml files but not .xul <https://groups.google.com/d/msg/firefox-dev/53dHw-tYYl0/b2YBKuMkAgAJ>, so we have increased lint coverage across the tree. Mark Banner also recently improved this support by handling self closing script tags <https://bugzilla.mozilla.org/show_bug.cgi?id=1602066> in xhtml files.

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 <https://arewefluentyet.com/>.
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 <https://bugzilla.mozilla.org/show_bug.cgi?id=1593091> 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 <https://groups.google.com/d/msg/firefox-dev/kCc44D9WZ38/SxEC9f0eBgAJ>. XUL has some “magic attributes” <https://groups.google.com/d/msg/firefox-dev/UuJISQiok38/I52n8tBlBgAJ> 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 <https://bugzilla.mozilla.org/show_bug.cgi?id=1596497>), and treat (b) as a separate project (metabug <https://bugzilla.mozilla.org/show_bug.cgi?id=1563415>). 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 <https://bugzilla.mozilla.org/show_bug.cgi?id=1566221>. 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.

Boris Zbarsky removed the concept of “content XBL scope” from sandboxes <https://bugzilla.mozilla.org/show_bug.cgi?id=1595890>.
Emilio revamped how we deal with anonymous content <https://bugzilla.mozilla.org/show_bug.cgi?id=1596209> by removing GetBindingParent and dealing with native anonymous content (NAC) and Shadow DOM separately. This work was broken out into a bunch of dependant bugs and allowed him to remove a bunch more now-dead code in Gecko.
Emilio also removed Remove nsGlobalWindowInner::mCachedXBLPrototypeHandlers <https://bugzilla.mozilla.org/show_bug.cgi?id=1596204>.
Emilio also removed the NODE_IS_ANONYMOUS_ROOT flag <https://bugzilla.mozilla.org/show_bug.cgi?id=1597123> on nsINode.
Emilio also removed document.getBindingParent and document.getAnonymousNodes <https://bugzilla.mozilla.org/show_bug.cgi?id=1596800>, which means there are no more XBL-related functions in Document.webidl. This also removed a number of synchronous layouts from frontend code that would cause XBL constructors to run (for example el.clientTop), and Mike Conley filed a bug to track removing any more instances of that pattern <https://bugzilla.mozilla.org/show_bug.cgi?id=1597318>.
Jan de Mooij removed JS::CloneFunctionObject and JS shell ‘clone’ function <https://bugzilla.mozilla.org/show_bug.cgi?id=1524590>, which were unused post-XBL.
Paolo Amadini removed the ensureXBLBindingAttached function from tabprompts.jsm <https://bugzilla.mozilla.org/show_bug.cgi?id=1584627>.
Christoph Walcher removed NS_NewXBLDocument <https://bugzilla.mozilla.org/show_bug.cgi?id=1596477>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20191216/e4a87252/attachment.html>


More information about the firefox-dev mailing list