This is the tenth edition of the XUL/XBL Replacement Newsletter. Since the last edition, we’ve stopped relying on two major components of the XBL implementation: “in-content” XBL and XBL stylesheets.
After recently landing UA Widget alternatives for <marquee>
, “plugin problem” UI, and the date / time picker,
we don’t need to rely on XBL in the content process anymore. This will
allow us to improve the security and performance of the content process
in Firefox.
It also makes the widgets themselves simpler, since they’re
implemented with more well-known technologies like frame scripts, JS
classes, and Shadow DOM (see the in-tree UA Widget docs for more information). There’s DevTools support as well - if you run this command you can see the UA Shadow DOM and <slot>
in the Inspector panel:
./mach run 'data:text/html,<marquee>slotted child</marquee>' --devtools --temp-profile --setpref devtools.inspector.showUserAgentShadowRoots=true
The next steps are to enable the UA widget pref by default in release, and then to remove the pref and start tearing out platform support. Barring any unforeseen issues, we expect to enable the pref by default in Firefox 65, and then start removing the feature in a subsequent release.
I’d like to again thank Tim Guan-tin Chien for leading this work, and to the many others who’ve been involved with planning, reviews, and patches. If you have a look at the metabug and graph tracking the number of bindings, you can see the amount of work involved. It took us on a tour of the DOM via scrollbars, video controls (on desktop and android), input fields (filepickers and datepickers), and even to unexpected places like the little resizer thing inside textareas, XML pretty printing and key handling inside input fields.
Back in June, Paolo Amadini announced that we were starting the process of migrating our XBL scoped stylesheets to be standard document-level author sheets. This would allow us to remove an extra unspecified CSS cascade level in the style engine, and make it easier for frontend developers to figure out which rule takes precedence over others based only on the specificity.
This work was broken down into individual bugs per stylesheet to make it easier to track regressions. Paolo, Dão Gottwald, and Tim Nguyen have been pushing this forward over the months. Recently, Dão took this over the finish line by converting some of the more tricky sheets (textbox.css, button.css, and toolbarbutton.css). All of the XBL stylesheets in chrome have now either been removed or ported into widgets.css.
We still have some leftovers to take care of before platform support can be removed (including deleting the preffed off in-content bindings as discussed above), but when we remove support it’ll be a significant simplification.
It used to be the case that the “Customizable UI” feature, along with many of the toolbars used in the primary browser chrome, required XBL to implement their behavior. Gijs Kruitbosch did a detailed breakdown of the work required to remove this dependency. Most of the bindings were able to be converted into plain JS instead of being attached to DOM nodes. In addition to helping burn down the number of bindings in the browser/ directory, this will give us more control over when to initialize different components during browser startup.
There are 94 bindings left, compared to 115 from the last update and 300 from the start of the project. Here’s a list of changes:
date-input
, time-input
, and datetime-input-base
bindings by creating a UA widget for input[type=date]
and input[type=time]
.marquee
bindings by creating a UA widget for <marquee>
, after I did some initial untangling by landing HTMLMarqueeElement.pluginProblem
by creating a UA widget for it.notification
and translationbar
bindings to Custom Elements.notificationbox
binding by converting it directly to a JS class, which allowed us to remove a layer of DOM between chrome and web content.toolbarpaletteitem
binding by updating CSS to remove the anonymous box needed to wrap children nodes.customizableui-toolbar-drag
binding by replacing the toolkit/ variation that it was extending with the more simple browser/ version.customizableui-toolbar
binding by moving it’s code directly into CustomizableUI.jsm.search-one-offs
binding by converting it into a Custom Element. Following up on this work, Dão converted it to a plain JS class and loaded it lazily which lets us do less work during DOMContentLoaded
.treecol
, treecol-base
, and treecol-image
bindings by converting them to a Custom Element.treebody
binding (which was mapped onto the <treechildren>
tag) by converting it to a Custom Element.tree-base
binding which was only providing a single helper function._______________________________________________
firefox-dev mailing list
firef...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev
That's very exciting! Did it save us much in the way of memory overhead?
-tom
1) By moving keyboard handling for inputs and `<browser>` elements out of XBL we saw a 48K memory win on the base content process memory: https://bugzilla.mozilla.org/show_bug.cgi?id=1419091.
2) Any time we executed JS inside of XBL it would have to create a new js-zone and increase the size of js-compartment. Here are some measurements I took a while back for that https://bugzilla.mozilla.org/show_bug.cgi?id=1426492#c10 (and in graph form at https://docs.google.com/spreadsheets/d/1ZJhGfZ92YlFRcqe4Ngst4AEs4QvoAHYR1oNXru-v0bk/edit#gid=0). This wasn't base overhead - it depended on those nodes being used inside of the DOM. So the main win here was for very common elements like scrollbars (removed in https://bugzilla.mozilla.org/show_bug.cgi?id=1432950). Stuff like `<marquee>` is pretty uncommon - and I definitely hope no pages have 1000+ marquees on them :).
There may be future wins around not enabling parts of the XBL service in the content process - I'm not sure if there's any constant overhead here or we only pay for it when a binding is loaded (and if so we would have already seen the win). I assume that removing parts of the implementation from the build should also help, but I don't have a good estimate of by how much.
Brian