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:
<textbox is="search">, for example.
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:
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
dropmarker, and removed the three associated bindings.
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.
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).
iframebinding (yes, we had a XBL binding for that!) by implementing a new
XULFrameElementsubclass used by the
toolbarpaletteitem-palettebinding and combined the
wizard-basebindings as part of the CSS work mentioned above.
scalebinding and supporting platform code.
autorepeatbuttonbinding by replacing it with a
toolbarbuttonin the one place it was used.
ctrlTab-previewbinding by implementing the feature directly in browser-ctrlTab.js.
replacementbinding, as part of his effort to remove in-content XBL.