Brian Grinstead

This is the first edition of the XBL Replacement Newsletter. First, as a reminder about the project: we are planning to replace XBL in Firefox (see this blog post for more details). There are 4 main focus areas for the project this quarter, so I’ll have a quick update on each:

1. Migrate a few bindings and update the plan based on what we learn

We’ve already been able to remove some bindings, I’ll highlight each of them at the end of the post. As for updating the plan - we’ve started to look at some of our our options for accessibility when moving away from XBL. At least for <image>, we decided to move the role assignment into C++ based on the tag name, but if we could find a way to expose the role from a Custom Element definition that would allow us to keep the role in the frontend. That part is a bit TBD for now while we are still working on XUL support in Custom Elements.

2. Land XUL support for Custom Elements

There has been some progress on the platform side here, mostly happening in Bug 1404420 and blockers.

Once we have platform support we’ll still need to figure some things out for the frontend, like how to load the scripts and stylesheets needed for the Custom Elements. Since XBL scripts are loaded via CSS and styles are specified via <resources>, we don’t have an exact analog. I’ve been taking a preliminary look into our options in Bug 1411707. We’ll ultimately have to do some performance testing to see what works best.

3. Improve tooling to make converting bindings easier

There’s a new website https://arewexblstill.com that contains tooling and dashboards. I’d like to thank Potch for helping with the site - he helped with the scripts that process XBL and also maintains a node XML parsing library that makes it easy.

This site has a timeline of binding removals and additions, a set of graphs showing various metrics (# of bindings, LOC, LOC per binding, and most used bindings), and a component tree showing inheritance hierarchy of bindings. There’s also an online XBL to Custom Element converter which is useful for prototyping.

4. Begin a bug breakdown for individual bindings

While we are working on Custom Element support, there’s still plenty of work that can be done. Sometimes when looking at a binding we realize that it’s never used or that it’s trivially extending another binding and can be folded into the parent. It’s not an exact science, but I’ve been looking for such bindings in the component tree and filing bugs. If you know of any bindings that can be removed, please file a bug blocking the De-XBL meta.

Bindings that have been removed so far

We have “only” 289 more bindings to go. That’s a lot, but we started with around 300.

We’ve removed 7 bindings so far: “tabbrowser-tabbox”, “image”, “radio” (windows-specific), “radio-with-spacing” (linux-specific), “checkbox-baseline”, and “checkbox-radio”, “panebutton”. There are 4 other bindings that’ve been removed but not specifically as part of the project: “plugin-popupnotification-center-item”, “click-to-play-plugins-notification”, “history-dropmarker”, “menuitem-iconic-tooltip”

OK, now for some of the changes:

• Paolo removed the image binding by moving the small amount of XBL code it had into XUL. This is an important one because although it had very little code, it accounts for around 25% of XBL instances created during a mochitest-browser run:
• Dão removed the Windows and Linux radio overrides (“radio”, “radio-with-spacing”). In the process we found that the only other binding (“toolbarpaletteitem-spacer”) in toolkit/themes/windows/global/globalBindings.xml was unused and we could delete the entire file
• Mossop removed the unused checkbox-baseline and checkbox-radio bindings
• I removed tabbrowser-tabbox in favor of a new attribute on tabbox instead, and also removed the viewbutton binding and the pageInfo.xml file that it was in.