<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=""><p class="">This is the twelfth edition of the XUL/XBL Replacement Newsletter. Since the last edition, we’ve Custom-Element’ified XUL trees, removed a complex XBL platform feature, and removed a bunch of bindings.</p><h2 id="xul-trees-no-longer-use-xbl" class=""><span style="font-size: 12px;" class="">XUL trees no longer use XBL</span></h2><p class="">XUL <code class="highlighter-rouge"><tree></code> elements are used for rendering important parts of Firefox, like the Places UI. They are implemented partly in C++ and partly in JS. Though similar functionality and performance can now be achieved in JS alone, the full migration away from this element is a big project that relies on a number of moving parts. Victor Porof has put together a <a href="https://docs.google.com/document/d/1lrWIAKTGfyO8_FaAScUc9V57jyZdM-odig00MmFh9HA/edit" class="">more detailed document</a> outlining the state of things here.</p><p class="">Because of this, we decided it would be helpful to <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1523957" class="">migrate the JS portion of XUL trees</a> out of XBL and into Custom Elements to unblock the XBL removal project. This was after already having removed bindings for child elements over the last few months (including <code class="highlighter-rouge">tree-base</code>, <code class="highlighter-rouge">treecols</code>, <code class="highlighter-rouge">treecol-base</code>, <code class="highlighter-rouge">treecol</code>, <code class="highlighter-rouge">treecol-image</code>, <code class="highlighter-rouge">columnpicker</code>, <code class="highlighter-rouge">treerows</code>, and <code class="highlighter-rouge">treebody</code>).</p><p class="">One challenge with this element was that it was using XBL <code class="highlighter-rouge"><children /></code> slotting that was hard to work around with light DOM alone. We’d tried to use Shadow DOM on other XBL migrations in the past, but <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1515518" class="">struggled to make it work</a> because we can’t nest a XBL element with <code class="highlighter-rouge"><children /></code> inside of a Shadow DOM <code class="highlighter-rouge"><slot /></code>. This means we can only use Shadow DOM if we know there’s never XBL slotted into the element, which is hard to guarantee in the general case. Luckily, <code class="highlighter-rouge"><tree></code>has a templated structure, we’ve de-XBL’ed its children, and instrumented the code at runtime to ensure no unsupported elements are inserted. So this means that <code class="highlighter-rouge"><tree></code> is the now first consumer of Shadow DOM in our chrome Custom Elements.</p><p class="">The migrated source can be seen in the MozTree class in <a href="https://searchfox.org/mozilla-central/source/toolkit/content/widgets/tree.js" class="">tree.js</a> and the MozPlacesTree class in <a href="https://searchfox.org/mozilla-central/source/browser/components/places/content/places-tree.js" class="">places-tree.js</a>.</p><h2 id="removing-the-ability-to-override-the-node-name-in-xbl" class=""><span style="font-size: 12px;" class="">Removing the ability to override the node name in XBL</span></h2><p class="">XBL had a feature which allowed a binding to override the node name of an element. For example, if there was a <code class="highlighter-rouge"><tab></code> element that had <code class="highlighter-rouge"><binding display="xul:button"></code> attached to it, then the element would pretend to be a <code class="highlighter-rouge"><button></code>.This was done by adding the <code class="highlighter-rouge">[display="xul:element"]</code> attribute, and also the <code class="highlighter-rouge">[extends="xul:element"]</code> syntax which (confusingly) did mostly the same thing.</p><p class="">This feature didn’t have an equivalent in the Web platform, was applied inconsistently inside Gecko, and wasn’t well understood. So Emilio Cobos Álvarez filed <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1450652" class="">bug 1450652</a> to track the work required to remove it.</p><p class="">Over time, we’ve either removed the bindings using this feature or removed the need for it within the binding. Usually this meant wiring up the proper CSS frame based on the real node name rather than the one defined in XBL, but there were lots of small mysteries to figure out for individual bindings along the way. Last week, Emilio removed the final consumer and also <a href="https://hg.mozilla.org/mozilla-central/rev/5edf9199407c" class="">removed the platform implementation</a>.</p><h2 id="binding-removals" class=""><span style="font-size: 12px;" class="">Binding Removals</span></h2><p class="">There are <a href="https://bgrins.github.io/xbl-analysis/#timeline" class="">55 bindings left</a>, compared to 78 from the last update and 300 from the start of the project. Here’s a list of changes:</p><ul class=""><li class="">Alex Surkov <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1525101" class="">removed the <code class="highlighter-rouge">browser-search-autocomplete-result-popup</code> binding</a> by converting it to a Custom Element. This also removed dependencies on the <code class="highlighter-rouge">autocomplete-rich-result-popup</code> and <code class="highlighter-rouge">urlbar-rich-result-popup</code> bindings, so they can now be deleted when QuantumBar ships.</li><li class="">Alex also <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1495622" class="">removed the <code class="highlighter-rouge">wizardpage</code> binding</a> by converting it to a Custom Element.</li><li class="">Alex also <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1455433" class="">removed the <code class="highlighter-rouge">checkbox</code> binding</a> by converting it to a Custom Element.</li><li class="">Alex also <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1527495" class="">removed the <code class="highlighter-rouge">text-link</code> binding</a> by converting it to a Custom Element that extends the <code class="highlighter-rouge">label</code> element with <code class="highlighter-rouge">[is]</code>.</li><li class="">Alex also <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1521306" class="">removed the <code class="highlighter-rouge">handler</code> binding</a> by converting it to a Custom Element that extends the <code class="highlighter-rouge">richlistitem</code> element with <code class="highlighter-rouge">[is]</code>.</li><li class="">Alex also <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1519486" class="">removed the <code class="highlighter-rouge">autocomplete-richlistitem</code> and <code class="highlighter-rouge">autocomplete-richlistitem-insecure-field</code> bindings</a> by converting them to Custom Elements that extend the <code class="highlighter-rouge">richlistitem</code> element with <code class="highlighter-rouge">[is]</code>.</li><li class="">Alex also <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1519533" class="">removed the <code class="highlighter-rouge">autocomplete-profile-listitem-base</code>, <code class="highlighter-rouge">autocomplete-profile-listitem</code>, <code class="highlighter-rouge">autocomplete-profile-listitem-footer</code>, <code class="highlighter-rouge">autocomplete-creditcard-insecure-field</code>, and <code class="highlighter-rouge">autocomplete-profile-listitem-clear-button</code> bindings</a> by converting them to Custom Elements that extend the <code class="highlighter-rouge">richlistitem</code> element with <code class="highlighter-rouge">[is]</code>.</li><li class="">Tim Nguyen <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1513343" class="">removed the <code class="highlighter-rouge">textarea</code> binding</a> by replacing instances directly with <code class="highlighter-rouge"><html:textarea></code>, a pattern we are planning to follow for <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1513325" class="">more xul textbox elements</a>.</li><li class="">Tim also <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1522290" class="">removed the <code class="highlighter-rouge">toolbarbutton-dropdown</code> binding</a> by implementing it in CSS.</li><li class="">Tim also <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1522279" class="">removed the <code class="highlighter-rouge">hardblockedaddon</code> and <code class="highlighter-rouge">softblockedaddon</code> bindings</a> by creating the DOM in JS from their single consumer.</li><li class="">Victor Porof <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1523957" class="">removed the <code class="highlighter-rouge">tree</code> and <code class="highlighter-rouge">places-tree</code> bindings</a> by converting them to Custom Elements.</li><li class="">I <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1527105" class="">removed the <code class="highlighter-rouge">menucaption</code> binding</a> by converting it to a Custom Element.</li><li class="">I also <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1487065" class="">removed the <code class="highlighter-rouge">popup-notification</code> and <code class="highlighter-rouge">addon-progress-notification</code> bindings</a> by converting them to Custom Elements.</li><li class="">Tim Guan-tin Chien <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1518932" class="">removed the <code class="highlighter-rouge">menulist</code> binding</a> by converting it to a Custom Element.</li><li class="">Tim also <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1518932" class="">removed the <code class="highlighter-rouge">menulist-popuponly</code> binding</a> by converting it to a Custom Element.</li><li class="">Special thanks to MattN for reviewing the many autocomplete richlistitem and popupnotification bindings.</li></ul><div class=""><br class=""></div></body></html>