<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="entry"><div class="entry"><div class="entry"><div class="entry"><p class="">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.</p>
<h2 id="common-keybindings-no-longer-use-xbl" class=""><font size="2" class="">Common Keybindings No Longer Use XBL</font></h2><p class="">It <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1419091#c0" class="">used to be the case</a> that we used XBL to handle certain keyboard shortcuts for elements like <code class="highlighter-rouge"><input></code> and <code class="highlighter-rouge"><textarea></code>, and for chrome-specific elements like <code class="highlighter-rouge"><editor></code> and <code class="highlighter-rouge"><browser></code>. For example, when you press <code class="highlighter-rouge">ctrl+c</code> in an input field an XBL handler would be triggered to copy selected text to the clipboard, or when you press <code class="highlighter-rouge">down</code>
in a browser it would scroll the page down. Mossop and Masayuki Nakano
took on the task of decoupling this key handling from XBL.</p><p class="">This led to a bunch of goodness. In the process of doing this, they:</p>
<ul class="">
<li class="">Added missing test coverage for these features.</li>
<li class="">Simplified how the whole system works by moving the handlers for
the keyboard shortcuts closer to the native keyboard shortcut handlers.</li>
<li class="">Saved 48K of memory overhead per content process.</li>
<li class="">Removed 20(!) XBL bindings, many of which were “in-content” - attached to elements and running scripts in the content process.</li>
</ul>
<h2 id="input-typefile-no-longer-uses-xul" class=""><font size="3" class=""><code class="highlighter-rouge"><input type=file></code></font><font size="2" class=""> no longer uses XUL</font></h2><p class="">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 <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1495153" class="">implemented that feature</a> using an HTML label in the file input, which also fixed <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1365434" class="">some cropping bugs</a> and <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1495153#c47" class="">improved support for mixed direction text</a> in filenames.</p>
<h2 id="custom-elements-in-the-payment-request-dialog" class=""><font size="2" class="">Custom Elements in the Payment Request Dialog</font></h2><p class="">Since the <a href="https://firefox-source-docs.mozilla.org/browser/components/payments/docs/index.html#dialog-architecture" class="">Payment Request dialog</a>
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 <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1496698" class="">was removed two weeks ago</a>,
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 (<a href="https://searchfox.org/mozilla-central/source/browser/components/payments/res" class="">source code</a>). We’ll be looking out ways to share some of these patterns with other Custom Elements in chrome going forward.</p>
<h2 id="browser-toolbox-window-as-html" class=""><font size="2" class="">Browser Toolbox Window As HTML</font></h2><p class="">The Browser Toolbox is set up as a separate Firefox process that passes in the <code class="highlighter-rouge">--chrome</code>
parameter to override the default window that opens when Firefox starts
up. This used to be a XUL window, but Honza Odvarko recently <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1488915" class="">updated it</a> so that the chrome window is HTML (<code class="highlighter-rouge">toolbox-process-window.html</code>).
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.</p><p class="">After this, Jason Laster wrote a post <a href="http://jasonlaster.github.io/devtools/2018/09/13/remote-toolbox.html" class="">explaining how to</a> open the Browser Toolbox using a Nightly binary to debug broken DevTools in a local build, updated with the new URL.</p>
<h2 id="binding-removals" class=""><font size="2" class="">Binding Removals</font></h2><p class="">There are <a href="https://bgrins.github.io/xbl-analysis/#timeline" class="">115 bindings left</a>, compared to 153 from the last update and 300 from the start of the project. Here’s a list of changes:</p>
<ul class="">
<li class="">Brendan Dahl <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1461798" class="">removed the <code class="highlighter-rouge">tooltip</code> binding</a>, implementing it as a XUL element subclass in C++.</li>
<li class="">Paolo <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1493844" class="">removed the <code class="highlighter-rouge">groupbox</code> and <code class="highlighter-rouge">caption</code> bindings</a>
by simplifying the consumers such that they didn’t need to rely on XBL
anonymous content anymore. In the process, the accessibility team <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1429940#c36" class="">identified some accessibility improvements</a> we could make to <a href="about:preferences" class="">about:preferences</a>, so Paolo is working on that now.</li>
<li class="">Paolo also <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1452626" class="">removed the <code class="highlighter-rouge">download</code> binding</a> after refactoring the Downloads UI to remove redundant elements.</li>
<li class="">Gijs Kruitbosch <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1500268" class="">removed the <code class="highlighter-rouge">customizableui-toolbar-menubar-stub</code> binding</a> by removing some legacy CustomizableUI code that was previously required for XUL addons.</li>
<li class="">Gijs also <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1499236" class="">removed the <code class="highlighter-rouge">customizableui-toolbar-menubar-autohide</code> binding</a> binding by moving the logic directly into browser-customization.js.</li>
<li class="">Kris Maglione removed the unused xpinstallConfirm.xul page, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1473933" class="">taking the <code class="highlighter-rouge">installitem</code> binding with it</a>.</li>
<li class="">Tim Nguyen <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1416363" class="">removed the <code class="highlighter-rouge">colorpicker</code> and <code class="highlighter-rouge">colorpicker-button</code> bindings</a>, by switching consumers to use <code class="highlighter-rouge"><input type="color"></code> directly.</li>
<li class="">Victor Porof <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1498740" class="">removed the <code class="highlighter-rouge">toolbar-menubar-autohide</code> binding</a>, which turned out to be unused and always overridden by our customizable UI bindings.</li>
<li class="">Alexander Surkov <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1491197" class="">migrated the <code class="highlighter-rouge">progressmeter</code> and <code class="highlighter-rouge">progressmeter-undetermined</code> bindings to a Custom Element</a>. Remaining consumers were then <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1428869" class="">replaced with an <code class="highlighter-rouge">html:progress</code></a> element directly.</li>
<li class="">Alexander also removed the <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1494529" class=""><code class="highlighter-rouge">text-label</code></a> and <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1494230" class=""><code class="highlighter-rouge">text-base</code></a> bindings by implementing a XUL element subclass that handles the core functionality for <code class="highlighter-rouge">label</code> and <code class="highlighter-rouge">description</code>.</li>
<li class="">I <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1476769" class="">migrated the <code class="highlighter-rouge">tabpanels</code> binding to a Custom Element</a>.</li>
<li class="">I <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1481949" class="">migrated the <code class="highlighter-rouge">radiogroup</code> binding to a Custom Element</a>.</li>
<li class="">I <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1460982" class="">migrated the <code class="highlighter-rouge">searchbar</code> binding to a Custom Element</a>.</li>
<li class="">I <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1492967" class="">merged the <code class="highlighter-rouge">remote-browser</code> binding into <code class="highlighter-rouge">browser</code></a>, in preparation to convert that to a Custom Element.</li>
<li class="">Mossop <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1419091" class="">landed the keybinding changes</a> discussed above. This removed the following bindings: <code class="highlighter-rouge">builtin-android-inputFields</code>, <code class="highlighter-rouge">builtin-android-textAreas</code>, <code class="highlighter-rouge">builtin-android-browser</code>, <code class="highlighter-rouge">builtin-android-editor</code>, <code class="highlighter-rouge">builtin-emacs-inputFields</code>, <code class="highlighter-rouge">builtin-emacs-textAreas</code>, <code class="highlighter-rouge">builtin-emacs-browser</code>, <code class="highlighter-rouge">builtin-emacs-editor</code>, <code class="highlighter-rouge">builtin-mac-inputFields</code>, <code class="highlighter-rouge">builtin-mac-textAreas</code>, <code class="highlighter-rouge">builtin-mac-browser</code>, <code class="highlighter-rouge">builtin-mac-editor</code>, <code class="highlighter-rouge">builtin-unix-inputFields</code>, <code class="highlighter-rouge">builtin-unix-textAreas</code>, <code class="highlighter-rouge">builtin-unix-browser</code>, <code class="highlighter-rouge">builtin-unix-editor</code>, <code class="highlighter-rouge">builtin-win-inputFields</code>, <code class="highlighter-rouge">builtin-win-textAreas</code>, <code class="highlighter-rouge">builtin-win-browser</code>, <code class="highlighter-rouge">builtin-win-editor</code>.</li>
</ul></div><ul class="">
</ul></div><ul class="">
</ul></div><ul class="">
</ul></div></body></html>