This is the fourth edition of the XBL Replacement Newsletter. Since the last update we’ve continued to remove bindings and have been making progress on accessibility, autocomplete widgets, and migrating XBL to JS. The easiest way to follow along with this work is to watch the main meta bug.
We moved all of the remaining [role]
attributes out of XBL and into the accessibility platform code. This work can be seen in Bug 1428930
and blockers. This is a big milestone since we will now be able to
migrate any binding to a Custom Element and maintain accessibility.
Also, we were able to delete the XBL accessibility platform integration
and eliminate a few more bindings that were only used to attach roles to
elements.
We used to have two separate implementations of the “autocomplete”
popup, which is used for combo boxes and for text input fields with an
attached drop-down. The older implementation was based on the <tree>
element, and in the past few years we’ve been replacing more and more of its uses with the new implementation based on the <richlistbox>
element, to overcome the styling and layout limitations of <tree>
.
It turned out that the separate search bar in the toolbar was the only instance that still depended on the intricacies of the <tree>
version, and once that was fixed we could convert all the other autocomplete popups to use the <richlistbox>
version, and remove the bindings that implemented a customized <tree>
for this use case.
Our largest binding (tabbrowser) was translated into a JS class using the converter script plus manual fixups. Thanks to the reviewers in that bug for sticking with it, and to Potch for upgrading his xmlom package to include XML comments. I’m hoping this same approach can apply to other large bindings, like <browser>
.
There are 215 more bindings left, compared to 240 from the last update and 300 from the start of the project. Here are the list of changes:
windowdragbox
binding by initializing the WindowDraggingUtils
on the titlebar in browser.js instead.tabbrowser
binding, after I converted the implementation into a JS class (above).menubutton-item
binding.autocomplete-result-popup
, autocomplete-base-popup
, autocomplete-tree
, autocomplete-treebody
, autocomplete-treerows
bindings.panelmultiview
binding.menulist-description
and menu-vertical
bindings.textbox[type=number]
and then simplified it to rely on <html:input type="number">
instead.feed
binding by building DOM using JS instead.toolbox
binding, which triggered some strange XBL construction behavior
that highlighted some of the subtleties with how XBL bindings get
attached. This led us to temporarily re-attach an empty binding to the
element while we made progress on the tabbrowser work.colorpickertile
binding by moving the accessibility role into platform code.menuitem-iconic-desc-noaccel
binding, as well as the unused listitem-checkbox-iconic
and listitem-checkbox-iconic
bindings.thumb
and scrollbar-base
bindings. This means that we don’t need to run JS in the content process when someone clicks on the scrollbar, which saves a bit of memory.root-element
binding which was attached to all :root
nodes by setting up lightweight themes in browser.js.