This is the ninth edition of the XBL Replacement Newsletter. Since the last update we’ve continued to remove “in-content” bindings, started using native Custom Elements in more chrome UI, and shipped a new top-level HTML window.
It used to be the case that we used XBL to handle certain keyboard shortcuts for elements like <input>
and <textarea>
, and for chrome-specific elements like <editor>
and <browser>
. For example, when you press ctrl+c
in an input field an XBL handler would be triggered to copy selected text to the clipboard, or when you press down
in a browser it would scroll the page down. Mossop and Masayuki Nakano
took on the task of decoupling this key handling from XBL.
This led to a bunch of goodness. In the process of doing this, they:
<input type=file>
no longer uses XULPreviously, we used a XUL label to render the filename inside of an HTML file input. This worked, but it meant that we were using XBL and XUL layout in the web page. We worked with UX to see if we could directly replace the XUL label with an HTML label, but ultimately decided that the “middle crop” feature provided by XUL labels was too important to lose when previewing file names. Thankfully, Mats Palmgren stepped in and implemented that feature using an HTML label in the file input, which also fixed some cropping bugs and improved support for mixed direction text in filenames.
Since the Payment Request dialog is fairly independent of the rest of the Firefox UI, it was developed from the beginning to not use XUL/XBL. Instead, it’s primarily written with unprivileged HTML using Custom Elements. The third-party polyfill that was initially used before Gecko’s Custom Element implementation was stable was removed two weeks ago, so the UI no longer has any external dependencies. It uses Custom Element mixins and an ES module to manage application state and allow for a reactive rendering model (source code). We’ll be looking out ways to share some of these patterns with other Custom Elements in chrome going forward.
The Browser Toolbox is set up as a separate Firefox process that passes in the --chrome
parameter to override the default window that opens when Firefox starts
up. This used to be a XUL window, but Honza Odvarko recently updated it so that the chrome window is HTML (toolbox-process-window.html
).
This also gave us a chance to remove some unused code and simplify how
we wire up commands in that window. Notably, it’s now the case that we
don’t render any top-level XUL windows in the Browser Toolbox process.
After this, Jason Laster wrote a post explaining how to open the Browser Toolbox using a Nightly binary to debug broken DevTools in a local build, updated with the new URL.
There are 115 bindings left, compared to 153 from the last update and 300 from the start of the project. Here’s a list of changes:
tooltip
binding, implementing it as a XUL element subclass in C++.groupbox
and caption
bindings
by simplifying the consumers such that they didn’t need to rely on XBL
anonymous content anymore. In the process, the accessibility team identified some accessibility improvements we could make to about:preferences, so Paolo is working on that now.download
binding after refactoring the Downloads UI to remove redundant elements.customizableui-toolbar-menubar-stub
binding by removing some legacy CustomizableUI code that was previously required for XUL addons.customizableui-toolbar-menubar-autohide
binding binding by moving the logic directly into browser-customization.js.installitem
binding with it.colorpicker
and colorpicker-button
bindings, by switching consumers to use <input type="color">
directly.toolbar-menubar-autohide
binding, which turned out to be unused and always overridden by our customizable UI bindings.progressmeter
and progressmeter-undetermined
bindings to a Custom Element. Remaining consumers were then replaced with an html:progress
element directly.text-label
and text-base
bindings by implementing a XUL element subclass that handles the core functionality for label
and description
.tabpanels
binding to a Custom Element.radiogroup
binding to a Custom Element.searchbar
binding to a Custom Element.remote-browser
binding into browser
, in preparation to convert that to a Custom Element.builtin-android-inputFields
, builtin-android-textAreas
, builtin-android-browser
, builtin-android-editor
, builtin-emacs-inputFields
, builtin-emacs-textAreas
, builtin-emacs-browser
, builtin-emacs-editor
, builtin-mac-inputFields
, builtin-mac-textAreas
, builtin-mac-browser
, builtin-mac-editor
, builtin-unix-inputFields
, builtin-unix-textAreas
, builtin-unix-browser
, builtin-unix-editor
, builtin-win-inputFields
, builtin-win-textAreas
, builtin-win-browser
, builtin-win-editor
.