This is the sixth edition of the XUL/XBL Replacement Newsletter. A quick note before starting: in addition to the ongoing XBL work, there’s been notable progress on other XUL projects. All of this work is interrelated enough that I think it makes sense to talk about it together, so I’ve updated the title to reflect that.
Since the last update we’ve shipped the first few Custom Elements in browser chrome, added better support for top-level HTML documents, and taken a decision on how to handle XBL stylesheets.
I’m happy to say that we’ve now shipped the first Custom Elements in browser chrome, which is the culmination of a lot of effort from the XBL and DOM teams. So, how does it work? Whenever a new chrome document gets created in the main process, we load a script called customElements.js which defines a base JS class (
MozXULElement) and ultimately calls
customElements.define for each element that we’ve implemented.
We are using normal web-exposed Custom Element APIs, with two chrome-only additions:
- We added a new setElementCreationCallback function, so we can wait to load scripts until the specified tag name is encountered. This will be especially important for elements that aren’t created in the startup path and take some time to load and parse (for instance, the findbar).
- The Custom Element spec only allows one element per tag name for “autonomous” elements, although it does allow customizing a few built-in elements. After discussing how to deal with tags that have multiple XBL bindings attached, we realized we needed more flexibility to ease migration and avoid rewriting major parts of the frontend. So we ported the “customized built-in” capability to XUL, while treating every XUL tag name as a “built-in”. This allows us to have different Custom Elements defined for
<textbox is="search">, for example.
Top Level HTML Support
When you open the Browser Console window, it now directly loads an HTML document. We used to first open a XUL wrapper document that would iframe the HTML document in order to support things like like window management, context menus, and tooltips. These features are now supported directly in top-level chrome HTML documents. This work is being continued in order to support the main browser window as HTML, and can be tracked in this metabug.
As Paolo explains in the XBL Replacement Newsletter Special Edition, we’ve taken a decision on how to migrate XBL stylesheets to standard document sheets. This will likely be spread out over two releases to give us time to fix any resulting regressions. The first set of work has landed, changing the sheets that were previously migrated as UA sheets to document sheets in widgets.css.
There are 176 bindings left, compared to 196 from the last update and 300 from the start of the project. Here’s a list of changes:
- Brendan Dahl removed XUL overlays.
- Brendan added window size persistence, context menu, and tooltip support to top-level HTML windows.
- Emma Malysz removed the custom
ScrollBoxObjectthat got created for
<scrollbox>tags, which let us pull some logic out of XBL and unblocked further changes to related bindings. We are planning to do something similar with
- I landed the first Custom Elements,
dropmarker, and removed the three associated bindings.
- I converted the
printpreviewtoolbarbinding to a Custom Element, taking advantage of the customized-built-in feature above so the behavior gets attached to
toolbar[is="printpreview-toolbar"]but not other toolbar elements.
- Julian Descottes greatly improved the DevTools support for anonymous content while working on Shadow DOM support in the markup view, which led to some long standing XBL inspection bugs being fixed. You’ll probably notice that ‘pick element’ feature is now working much better in the Browser Toolbox when inspecting menus, richlistboxes, etc.
- Mark Striemer converted all tabs popup to a photon panel, which greatly simplified and allowed me to remove the
- Mike Conley removed the
emptybinding after a deep dive into a mystery in which removing the binding caused performance regression. This was especially mysterious because the binding did nothing - the fix ultimately required changing when the ScriptPreloader window gets closed (read more here).
- Neil Deakin removed the
iframebinding (yes, we had a XBL binding for that!) by implementing a new
XULFrameElementsubclass used by the
- Paolo Amadini removed the
toolbarpaletteitem-palettebinding and combined the
- Paolo removed the
wizard-basebindings as part of the CSS work mentioned above.
- Paolo consolidated list styling, which allowed him to remove the
- Paolo removed the now-unused
scalebinding and supporting platform code.
- Paolo removed the
autorepeatbuttonbinding by replacing it with a
toolbarbuttonin the one place it was used.
- Paolo removed the
ctrlTab-previewbinding by implementing the feature directly in browser-ctrlTab.js.
- Tim Guan-tin Chien removed the in-content
replacementbinding, as part of his effort to remove in-content XBL.
- Tim implemented the setElementCreationCallback and customized built-in features mentioned above.