<div dir="ltr"><div class="entry">
    
    
    <p><font size="2">This is the eighth edition of the XBL Replacement Newsletter. 
Since the last update there’ve been steps towards removing in-content 
XBL, flexbox performance improvements, and new chrome Custom Element 
capabilities.</font></p>

<h2 id="gmail-in-content-xbl--ua-widgets"><font size="2">In Content XBL → UA Widgets</font></h2>

<p><font size="2">We have been using XBL inside web content for a long time for 
rendering UI like scrollbars. But there are even more complex situations
 where we use XBL to insert DOM and run JS inside the content document. 
For example, with <code class="gmail-highlighter-rouge"><video controls></code> or <code class="gmail-highlighter-rouge"><input type="date"></code>.</font></p>

<p><font size="2">Tim Guan-tin Chien has been busy working on an alternative to this setup. Now that <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1484048">bug 1484048</a>
 has landed, the video controls are working entirely without XBL in 
nightly builds. Instead, we are using Shadow DOM and JS running inside 
of a sandbox. The setup is coined “UA Widgets” - you can read more about
 the design in <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1431255">bug 1431255</a>.</font></p>

<p><font size="2">This setup is pretty complex, mostly because of the level of 
encapsulation needed. The web content must not be able to probe into the
 DOM inserted, nor interact with the JS directly. The sandboxes are 
created per-origin as an extra layer of security to ensure isolation 
among different origins in the same content process.</font></p>

<p><font size="2">Now that the first binding is done and the framework is in place, Tim
 is setting his sights on the rest. There aren’t too many in-content 
bindings left after this. The most complex ones are the date and time 
pickers, the marquee tag, and the “click to play” plugin UI. Once we 
remove the last one that’ll let us remove the in-content XBL 
implementation which we expect will provide performance, security, and 
code simplification benefits.</font></p>

<h2 id="gmail-flexbox-performance-improvements"><font size="2">Flexbox performance improvements</font></h2>

<p><font size="2">One of the main aspects of the UI that we’d like to migrate away from
 XUL and towards web standards is flexbox. One reason this is important 
is that it’ll make it easier to use HTML elements in the browser chrome.
 But the main thing I wanted to talk about here is that it creates a 
need to greatly improve the performance of CSS flexbox.</font></p>

<p><font size="2">Flexbox perf issues affect web content in Firefox - for example <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1377253">Twitter DMs</a>, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1376536">WhatsApp</a>, and <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1304473">number of other sites</a>. And as <a href="https://enndeakin.wordpress.com/2015/07/13/comparing-flexible-box-layouts/">Neil noticed in 2015</a>, switching the browser chrome to use CSS flexbox causes large perf regressions. To track this, we <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1398963">added a pref to enable CSS flexbox in the browser chrome</a> which lets us <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1449346">measure</a> the  difference between XUL and CSS flexbox with Talos.</font></p>

<p><font size="2">In order to improve performance in both these environments (web 
content, and chrome with CSS flex layout), the layout team has 
prioritized optimizing  flexbox during the second half of this year. 
Daniel Holbert landed the first major piece of this effort recently in <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1490890">Bug 1490890</a>.
 This had a massive impact on some DevTools panels that are already 
using CSS flex, especially the webconsole. As Nicolas Chevobbe <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1485084#c7">noted</a>, one console test case where characters get typed into the input field sped up from ~800ms to ~100ms.</font></p>

<p><font size="2">It’s still TBD when it’ll get fast enough to lay out the browser 
chrome, but each step in that direction will make websites using flexbox
 faster in Firefox. Keep an eye on the main <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1304473">flexbox performance metabug</a> if you want to follow along.</font></p>

<h2 id="gmail-xpcom-support-for-chrome-custom-elements"><font size="2">XPCOM support for (chrome) Custom Elements</font></h2>

<p><font size="2">XBL has a way to wire up XPCOM interfaces with DOM elements. You may 
have seen this before inside of XBL bindings - for example the <code class="gmail-highlighter-rouge">browser</code> binding uses <a href="https://searchfox.org/mozilla-central/rev/21588b2a9824e0758fe11d10065e2c01ea9f32be/toolkit/content/widgets/browser.xml#15"><code class="gmail-highlighter-rouge">implements="nsIObserver, nsIBrowser"</code></a>.
 This lets the XBL binding provide the implementation for functions on 
that interface, and lets other code QueryInterface to that interface 
using the element.</font></p>

<p><font size="2">This feature is (obviously) not part of the specification for Custom Elements. But if you look closely at our <a href="https://bgrins.github.io/xbl-analysis/tree/">tree of XBL bindings</a>, you can see that a bunch of them inherit from <code class="gmail-highlighter-rouge">basecontrol</code> which relies on this feature. That means we’ve been blocked off from migrating most of those bindings to Custom Elements.</font></p>

<p><font size="2">We are unblocking this on two fronts:</font></p>

<ol><li><font size="2">Adding XPCOM support to chrome Custom Elements. This is done - Neil Deakin landed this feature in bugs <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1461742">1461742</a> and <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1478372">1478372</a>.</font></li><li><font size="2">Remove individual interfaces when possible. Alex Surkov recently removed <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1488620"><code class="gmail-highlighter-rouge">nsIDOMXULLabelElement</code></a>, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1492046"><code class="gmail-highlighter-rouge">nsIDOMXULLabeledControlElement</code></a>, and <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1486674"><code class="gmail-highlighter-rouge">nsIDOMXULCheckboxElement</code></a>, for example. This also has some overlap with the work bz did to remove <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1455674"><code class="gmail-highlighter-rouge">nsIDOMElement</code></a> and <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1455676"><code class="gmail-highlighter-rouge">nsIDOMNode</code></a> a few months back, and we’re hoping to do more of this when it makes sense.</font></li></ol>

<h2 id="gmail-binding-removals"><font size="2">Binding Removals</font></h2>

<p><font size="2">There are <a href="https://bgrins.github.io/xbl-analysis/#timeline">153 bindings left</a>, compared to 161 from the last update and 300 from the start of the project. Here’s a list of changes:</font></p>

<ul><li><font size="2">I <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1411707">migrated <code class="gmail-highlighter-rouge"><findbar></code> to a Custom Element</a>, which let us remove the <code class="gmail-highlighter-rouge">findbar</code> and <code class="gmail-highlighter-rouge">findbar-textbox</code>
 bindings. This was one of the earlier Custom Element migration bugs on 
file so it’s a good opportunity to look back on the work that’s been 
done to unblock it - see the <a href="https://bugzilla.mozilla.org/showdependencytree.cgi?id=1411707&hide_resolved=0">dependency tree</a>  to get a sense for that.</font></li><li><font size="2">I also <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1469902">migrated <code class="gmail-highlighter-rouge">tabbox</code> to a Custom Element</a>, and then Dão Gottwald removed <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1486845">some unused code paths</a> that we discovered during the review.</font></li><li><font size="2">Paolo Amadini <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1457218">removed</a> the unused <code class="gmail-highlighter-rouge">menu-button</code> and <code class="gmail-highlighter-rouge">menu-button-base</code> bindings.</font></li><li><font size="2">Paolo also <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1457216">removed the <code class="gmail-highlighter-rouge">menulist-editable</code></a> binding.</font></li><li><font size="2">Tim added the UA Widget capability discussed above, which let us remove <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1431255"><code class="gmail-highlighter-rouge">videoControls</code></a>, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1431255"><code class="gmail-highlighter-rouge">noControls</code></a>, and <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1437956"><code class="gmail-highlighter-rouge">prettyprint</code></a> bindings. Notably, this caused the second biggest one day drop in lines of XBL code in m-c that we’ve had so far.</font></li></ul><div><br></div>

  </div></div>