XUL/XBL Replacement Newsletter #8
Brian Grinstead
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.
In Content XBL → UA Widgets
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 <video controls> or <input type="date">.
Tim Guan-tin Chien has been busy working on an alternative to this setup. Now that bug 1484048 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 bug 1431255.
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.
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.
Flexbox performance improvements
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.
Flexbox perf issues affect web content in Firefox - for example Twitter DMs, WhatsApp, and number of other sites. And as Neil noticed in 2015, switching the browser chrome to use CSS flexbox causes large perf regressions. To track this, we added a pref to enable CSS flexbox in the browser chrome which lets us measure the difference between XUL and CSS flexbox with Talos.
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 Bug 1490890. This had a massive impact on some DevTools panels that are already using CSS flex, especially the webconsole. As Nicolas Chevobbe noted, one console test case where characters get typed into the input field sped up from ~800ms to ~100ms.
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 flexbox performance metabug if you want to follow along.
XPCOM support for (chrome) Custom Elements
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 browser binding uses implements="nsIObserver, nsIBrowser".
This lets the XBL binding provide the implementation for functions on
that interface, and lets other code QueryInterface to that interface
using the element.
This feature is (obviously) not part of the specification for Custom Elements. But if you look closely at our tree of XBL bindings, you can see that a bunch of them inherit from basecontrol which relies on this feature. That means we’ve been blocked off from migrating most of those bindings to Custom Elements.
We are unblocking this on two fronts:
- Adding XPCOM support to chrome Custom Elements. This is done - Neil Deakin landed this feature in bugs 1461742 and 1478372.
- Remove individual interfaces when possible. Alex Surkov recently removed
nsIDOMXULLabelElement,nsIDOMXULLabeledControlElement, andnsIDOMXULCheckboxElement, for example. This also has some overlap with the work bz did to removensIDOMElementandnsIDOMNodea few months back, and we’re hoping to do more of this when it makes sense.
Binding Removals
There are 153 bindings left, compared to 161 from the last update and 300 from the start of the project. Here’s a list of changes:
- I migrated
<findbar>to a Custom Element, which let us remove thefindbarandfindbar-textboxbindings. 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 dependency tree to get a sense for that. - I also migrated
tabboxto a Custom Element, and then Dão Gottwald removed some unused code paths that we discovered during the review. - Paolo Amadini removed the unused
menu-buttonandmenu-button-basebindings. - Paolo also removed the
menulist-editablebinding. - Tim added the UA Widget capability discussed above, which let us remove
videoControls,noControls, andprettyprintbindings. Notably, this caused the second biggest one day drop in lines of XBL code in m-c that we’ve had so far.
Felipe G
_______________________________________________
firefox-dev mailing list
firef...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev
Tim Guan-tin Chien
Felipe G
Robert Helmer
automatically be published to http://firefox-source-docs.mozilla.org/
provided your part of the tree opts-in to it:
https://groups.google.com/forum/#!topic/firefox-dev/p2mOCab9Ufg
Dão Gottwald
Brian Grinstead
Brian
Brian Grinstead
Brian
> On Sep 24, 2018, at 10:22 PM, Shelby E <shele...@gmail.com> wrote:
>
> With these changes and new API's will these be useable independently of firefox builds? As in, creating custom components without XUL that will be future compatible? Or is all this replaceable at any time?
