XUL/XBL Replacement Newsletter #8

502 views
Skip to first unread message

Brian Grinstead

unread,
Sep 24, 2018, 11:36:58 AM9/24/18
to firefox-dev

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:

  1. Adding XPCOM support to chrome Custom Elements. This is done - Neil Deakin landed this feature in bugs 1461742 and 1478372.
  2. Remove individual interfaces when possible. Alex Surkov recently removed nsIDOMXULLabelElement, nsIDOMXULLabeledControlElement, and nsIDOMXULCheckboxElement, for example. This also has some overlap with the work bz did to remove nsIDOMElement and nsIDOMNode a 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:


Felipe G

unread,
Sep 24, 2018, 3:56:48 PM9/24/18
to Firefox Dev
This is an impressive amount of work! Great to hear about all this progress!

I'm interested in learning more about the UA Widgets API.. Will there be a write up or some documentation about how the final API works? I saw the bug but it's too daunting to get all the information from there.

Felipe

_______________________________________________
firefox-dev mailing list
firef...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev

Tim Guan-tin Chien

unread,
Sep 24, 2018, 4:08:11 PM9/24/18
to fel...@gmail.com, Firefox Dev
Hi Felipe,

Thanks for the suggestion on documenting the APIs. I am not sure where will be the best place to put it, but for the sake of making sure it is updated, I am leaning toward adding it as a big comment in UAWidgetsChild.jsm, where all the widgets are being initialized.

Let me know what you think. Thanks.


Tim

Felipe G

unread,
Sep 24, 2018, 4:15:39 PM9/24/18
to timd...@mozilla.com, Firefox Dev
Sounds good to me :)

Robert Helmer

unread,
Sep 24, 2018, 5:38:22 PM9/24/18
to timd...@mozilla.com, fel...@gmail.com, firefox-dev
You can write your comments in JSDoc style and API docs will
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

unread,
Sep 25, 2018, 8:57:55 AM9/25/18
to Brian Grinstead, firefox-dev
I also converted toolbarbutton.css from an XBL stylesheet to a document one. This was a bit tricky because we override toolbarbutton.css in many places. Still dealing with remaining fallout.

dao

Brian Grinstead

unread,
Sep 25, 2018, 9:34:38 AM9/25/18
to Dão Gottwald, firefox-dev
Thanks for taking those. I should have mentioned that one, and and other document stylesheet conversions blocking https://bugzilla.mozilla.org/show_bug.cgi?id=1470830. Those are unblocking Custom Element migrations, and also once we remove the last XBL <resources> sheet we'll be able to remove platform support for the special XBL cascade level and scoping rules.

Brian

Brian Grinstead

unread,
Sep 25, 2018, 9:52:34 AM9/25/18
to Shelby E, firef...@mozilla.org
These elements do work with other toolkit apps, but specific elements and APIs will change over time much in the same way that individiual XBL bindings would.

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?

Shelby E

unread,
Sep 26, 2018, 4:34:13 PM9/26/18
to bgrin...@mozilla.com, firef...@mozilla.org
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?


On Mon, Sep 24, 2018 at 10:36 AM Brian Grinstead <bgrin...@mozilla.com> wrote:

Tim Guan-tin Chien

unread,
Oct 8, 2018, 6:15:50 PM10/8/18
to Helmer, Robert, fel...@gmail.com, Firefox Dev
To close the loop here — the in-tree document is now published at

Reply all
Reply to author
Forward
0 new messages