XUL/XBL Replacement Newsletter 9

This is the ninth edition of the XUL/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.

Common Keybindings No Longer Use XBL

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:

  • Added missing test coverage for these features.
  • Simplified how the whole system works by moving the handlers for the keyboard shortcuts closer to the native keyboard shortcut handlers.
  • Saved 48K of memory overhead per content process.
  • Removed 20(!) XBL bindings, many of which were "in-content" - attached to elements and running scripts in the content process.

<input type=file> no longer uses XUL

Previously, 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.

Custom Elements in the Payment Request Dialog

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.

Browser Toolbox Window As HTML

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.

Binding Removals

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: