<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="entry"><p class="">This is the fourteenth edition of the XUL/XBL Replacement
Newsletter. Since the last edition, we’ve shipped browser.xhtml, started
the process of removing the rest of the XUL documents in the tree, and
continued to remove more XBL bindings.</p>
<h2 id="shipping-browserxhtml" class=""><span style="font-size: 12px;" class="">Shipping browser.xhtml</span></h2><p class="">As of this week the main browser window <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1534407" class="">is no longer a XUL document</a>. Also, the hidden XUL window (which is used on mac to provide menus when no browser window is visible) has been <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1551334" class="">converted to XHTML</a>. You (hopefully) didn’t notice this change in the UI but it’s the culmination of <em class="">a lot</em> of work, most notably by Brendan Dahl.</p><p class="">After we got the tree pretty much green with browser.xhtml (~75 bugs <a href="https://bugzilla.mozilla.org/showdependencytree.cgi?id=1453783&maxdepth=1&hide_resolved=0" class="">tracked mostly on the top-level html metabug</a> and also <a href="https://groups.google.com/d/msg/firefox-dev/Q19KiHk6VC4/Af7PCGIKAQAJ" class="">detailed in newsletter #7</a>),
we began a performance investigation. We would have liked to have been
able to load the browser window through the regular web-exposed HTML
loading path, but investigation showed that getting to first paint in
XHTML was slower than in XUL. Specifically, Talos performance tests
showed regressions in tests that timed opening new browser windows or
restoring the browser on startup.</p><p class="">The main reasons were that in XUL (1) we skip the XML parser in the
“warm” startup case which Talos covers, and (2) we begin layout later,
after the DOM is ready. We tried a bunch of workarounds for these. For
example: making the document nearly empty and importing a shared
fragment from JS, preventing early layout by hiding elements or
suppressing it from Gecko, changing when various events fire in the
document lifecycle. We would see incremental improvements with each
approach, but nothing that reached the goal of parity with current
performance, which is sensitive to even minor changes in the window
opening time.</p><p class="">At the end of the investigation, we had learned enough about the
internals here that it seemed viable to expand prototype cache support
to XHTML documents as well. So the implementation was <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1527977" class="">moved</a> out of <code class="highlighter-rouge">XULDocument</code> and into <code class="highlighter-rouge">PrototypeDocumentParser</code> and <code class="highlighter-rouge">PrototypeDocumentContentSink</code>. Thanks a lot to Smaug for the guidance and reviews in this process.</p><p class="">I still hold out hope that someday the normal loading path with a bit
of tuning will be fast enough for our use-cases, but in the meantime
this approach has a few nice benefits:</p>
<ul class="">
<li class="">The faster path is now enabled automatically for any <code class="highlighter-rouge">chrome://</code> XHTML document.</li>
<li class="">It nearly emptied out what was left of the <code class="highlighter-rouge">XULDocument</code> implementation, which sets the stage for the rest of the XUL document burndown project - more on that below.</li>
<li class="">We could expand support to other chrome document types if we’d like (for instance, SVG).</li>
</ul><p class="">What’s next? We are planning to <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1492582" class="">migrate the root <code class="highlighter-rouge"><xul:window></code> element to <code class="highlighter-rouge"><span class="nt"><html></span></code></a>, which will make the Browser Toolbox highlighters <a href="https://bugzilla.mozilla.org/attachment.cgi?id=9067141" class="">work like they do for web content</a>. We’ll also <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1553188" class="">rename the file</a>
in tree from browser.xul to browser.xhtml: we were waiting to make sure
it stuck before doing any file moves since that can break in-flight
patches.</p>
<h2 id="xul-document-burndown" class=""><span style="font-size: 12px;" class="">XUL document burndown</span></h2><p class="">We are also starting on a plan to remove all XUL documents from mozilla-central. Based on feedback from a <a href="https://groups.google.com/d/msg/mozilla.dev.platform/LXsSeAnJpbc/Z4x8i605AgAJ" class="">dev-platform post outlining the plan</a>,
we are going to adjust it to not focus as much on converting straight
to .html and aim for .xhtml for most documents. See the post for more
details but from a high level this looks like:</p>
<ol class="">
<li class="">Load all XUL documents as XHTML using the prototype cache. This
doesn’t require any file renaming, we will just detect a .xul file and
act like it’s .xhtml. This is tracked in <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1550801" class="">Bug 1550801</a></li>
<li class="">Delete the XULDocument implementation.</li>
<li class="">For most files, rename .xul->.xhtml. In this case everything
should work identically with the file name changed since it’s already
being loaded as such with (1). The main extra task here is to update
bug, code, and comments referencing the old file name</li>
<li class="">For the now-xhtml documents apply cleanups when appropriate. For instance, migrate <code class="highlighter-rouge"><xul:window></code>-><code class="highlighter-rouge"><html></code>, convert ProcessingInstruction stylesheets to <code class="highlighter-rouge"><link></code>, etc. We’d like to automate this as much as possible since there are over 1500 xul documents in the tree.</li>
</ol><p class="">This work is being tracked in the following <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1540278" class="">metabug</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="">33 bindings left</a>, compared to 44 from the last update and 300 from the start of the project. Here’s a list of changes:</p>
<ul class="">
<li class="">Andrew Swan <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1538983" class="">converted the <code class="highlighter-rouge">button</code> and <code class="highlighter-rouge">button-menu</code> bindings into a Custom Element</a>.</li>
<li class="">Andrew <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1519577" class="">converted the <code class="highlighter-rouge">toolbarbutton</code> and <code class="highlighter-rouge">toolbarbutton-badged</code> bindings into a Custom Element</a>, which allowed us to remove <code class="highlighter-rouge">button-base</code> in the process.</li>
<li class="">I <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1448213" class="">converted <code class="highlighter-rouge">label-control</code> into a Custom Element</a>.
This also made accessKey formatting more consistent - the underlined
accessKey won’t get dropped anymore when textContent on an element is
updated, for instance.</li>
<li class="">I <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1500626" class="">converted the <code class="highlighter-rouge">menuitem</code>, <code class="highlighter-rouge">menuitem-iconic</code>, and <code class="highlighter-rouge">menuitem-iconic-noaccel</code> bindings to a Custom Element</a>, which allowed us to remove <code class="highlighter-rouge">menuitem-base</code> in the process.</li>
<li class="">Tim Nguyen <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1521280" class="">converted <code class="highlighter-rouge">search-textbox</code> to a Custom Element</a>, and also started to <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1513325" class="">break down work</a> to convert plain textboxes to html:inputs.</li>
</ul></div></body></html>