This is the seventh edition of the XUL/XBL Replacement Newsletter. Since the last edition, we’ve gotten some tooling improvements, landed an experimental HTML browser window and removed a bunch of listbox code.
As you may have heard, Custom Elements and Shadow DOM are riding the train for 63. The DevTools team has also done a lot of work to make sure we have good tooling for these features.
One of these features that I’d like to mention is called “Show Custom Element definition”. A badge appears next to a Custom Element in the Inspector, and when you click on that it takes you directly to your Custom Element class in the Debugger. This also works in the Browser Toolbox and can be seen on any of the Custom Elements we currently ship in the browser window. For example: search for “moz-input-box” nodes in the Inspector to try it.
This highlights some benefits to using web standard tech within the Firefox frontend. We get to use the same DevTools features that we’re shipping to web devs. And (at least in my experience) Firefox devs are quite likely to give feedback and file bugs on tools, which ends up improving those same features.
Finally, I’d like to point out that coordinating the release of a complex platform feature and tooling to go with it is hard to do. It takes a lot of planning and cooperation between the the DOM and DevTools teams. Thanks to Julian Descottes, Belén Albeza, Emilio Cobos Álvarez, Jim Blandy, and many others for making this happen.
The main browser window is currently a XUL document with (mostly) XUL elements in the DOM. We’d ultimately like to support an HTML document with (mostly) HTML elements in the DOM. That’s a long road, though. One milestone we hope to hit along the way is loading an HTML document with (mostly) XUL elements in the DOM.
Practically, this can be done by loading a browser.xhtml file with the same markup as browser.xul. This will allow us to audit and fix issues affecting top-level HTML windows without rewriting the browser window from scratch. And since we have a large suite of browser tests to track progress against, we can be pretty confident about what’s working and what’s still broken. We’ll be tracking that in the top-level HTML metabug
An experimental version of this has now landed. you can try it out by adding this to your .mozconfig
file: mk_add_options 'export MOZ_BROWSER_XHTML=1'
. It’s worth calling out some of the changes we made to set thi up, so I’ve split them into two groups below.
First group: burning down XULDocument.webidl so that the browser JS doesn’t rely on XUL-specific APIs. This is now finished - see the webidl file when we started vs now. Here are some notable changes:
document.persist
to Services.xulStore.persist
(bug 1476030, firefox-dev post).document.width
and document.height
from XULDocument (bug 1475305).document.getElementsByAttribute[NS]
from XULDocument to ParentNode, so it supports all chrome documents and elements (bug 1475342).popupNode
, popupRangeParent
, popupRangeOffset
, and tooltipNode
from XULDocument to Document (bug 1480206).addBroadcastListenerFor
and removeBroadcastListenerFor
(bug 1482170).Second group: adapting the frontend to work while running inside of an HTML document. This is ongoing, here are some of the changes so far:
document.createElement
in browser JS to document.createXULElement
to explicitly construct XUL elements even when the document namespace is HTML (bug 1479050).node.firstChild
and assume it’s an element. For that to work in HTML documents callers were rewritten as node.firstElementChild
(bug 1479125, firefox-dev post).<broadcaster>
and <observer>
(which only work in XUL documents) in browser.xul (bug 1479908).Thanks to everyone who’s helped with planning, patches, and reviews so far. In particular I’d like to acknowledge Brendan Dahl and Mossop for pushing this forward.
We don’t have any <listbox>
elements in Firefox anymore. If that sounds surprising, like saying “we
don’t have any buttons in Firefox anymore”, there’s a distinction to be
made as we still use a lot of lists in the UI.
Previously, there were two main widgets to choose from when rendering a list in chrome: <listbox>
and <richlistbox>
.
Richlistbox is more powerful and more “webby”, and over the course of
time most of the UI was updated to use it. Listbox relied on custom
layout code to guarantee that the height of a list was a multiple of the
height of a row, and handle scrolling differently. This can be useful,
but it just wasn’t required for the remaining consumers.
Since only a few <listbox>
elements were left, it was a pretty easy decision to remove it and unify on a single list widget. Being able to support just richlistbox
lets us focus effort on it and makes it easier to decide what to use when adding new UI. It also allowed us to delete around 3K lines of platform code and 2K lines of frontend code.
Finally, it’s worth mentioning that the <tree>
element is implemented similarly to <listbox>
, but with more features. This element is on our radar for replacement
in the coming year, but it will be more work because we have many
instances of trees in Firefox and those UIs are more complex and
performance sensitive than listboxes.
There are 161 bindings left, compared to 176 from the last update and 300 from the start of the project. Here’s a list of changes:
editor
binding to a Custom Element, with help from Mossop who made it so we can extend XULFrameElement with Custom Elements, which will come in handy for converting the <browser>
tag.input-box
and input-box-spell
to Custom Elements. These are part of the anonymous content used to build XUL <textbox>
tags.tabbrowser-tabpanels
binding along with the tabbrowser-browser
and tabbrowser-remove-browser
bindings by moving the logic directly into tabbrowser.tab-base
binding by loading the stylesheet into children bindings directly.<listbox>
, as referenced above. This allowed us to remove a bunch of bindings: listbox-base
, listitem
, listheader
, listbox
, listrows
, listitem-checkbox
, listcell
, listcell-checkbox
, and listhead
(bug 1476611, bug 1474258, bug 1472555).How is this going to work with the XUL prototype cache? My understanding was
that, if anything, we'd probably initially aim for a XUL document with mostly
XHTML elements so that we could continue using the XUL prototype cache until
we have a replacement.
_______________________________________________
firefox-dev mailing list
firef...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev
> On Aug 23, 2018, at 9:29 PM, Kris Maglione <kmag...@mozilla.com> wrote:
>
> On Thu, Aug 23, 2018 at 08:59:32PM -0700, Brian Grinstead wrote:
>> The main browser window is currently a XUL document with (mostly) XUL elements in the DOM. We’d ultimately like to support an HTML document with (mostly) HTML elements in the DOM. That’s a long road, though. One milestone we hope to hit along the way is loading an HTML document with (mostly) XUL elements in the DOM.
>
> How is this going to work with the XUL prototype cache?
It’s a good point, and we still need to figure out what to do about the prototype cache. We’ll do that in parallel with fixing bugs - once we're confident that the HTML doc is working approximately the same as the XUL doc we’ll start tracking any regressions in talos. Since we’re going to have to do this ultimately regardless of what direction we go, I hope it’s not a major roadblock.
We have some talos pushes in flight to compare the impact of turning off various parts of the cache (script, style, document) - I’ll update you as we start to get some results from that. I’m not super familiar with this area yet, and would welcome feedback and ideas about how to enable some or all of it for HTML documents.
> My understanding was that, if anything, we'd probably initially aim for a XUL document with mostly XHTML elements so that we could continue using the XUL prototype cache until we have a replacement.
The tricky part with going the other direction (XUL doc, HTML elements) is that we have elements that are still XUL, and the XUL flexbox layout and CSS layouts don’t play well together. So migrating parts of the UI at a time into HTML elements is going to cause CSS/layout headaches unless if the parts can be pretty isolated from each other. I’m not sure I can describe all the problems exactly, but I’ve experienced this first hand when trying to put HTML inside XUL parents in the Inspector panel - things just don’t display correctly and the behavior isn’t specified AFAIK. I can dig up some bugs if you’re interested in details.
The plan to avoid that problem is to wait for XUL flexbox emulation, which will flip the entire UI to use CSS flexbox and unblock us to begin interspersing XUL and HTML elements. This is blocked primarily on CSS flexbox perf, which is being worked on by the layout team (see bug 1449346 and the metabug 1304473).
Brian
That sounds reasonable. Just as long as we're not overlooking it.
>I’m not super familiar with this area yet
At this point, I can probably count on one hand the people who are.
Hopefully we'll wind up in a better place at the end of this process.
>The tricky part with going the other direction (XUL doc, HTML elements) is
>that we have elements that are still XUL, and the XUL flexbox layout and
>CSS layouts don’t play well together. So migrating parts of the UI at a
>time into HTML elements is going to cause CSS/layout headaches unless if
>the parts can be pretty isolated from each other. I’m not sure I can
>describe all the problems exactly, but I’ve experienced this first hand
>when trying to put HTML inside XUL parents in the Inspector panel - things
>just don’t display correctly and the behavior isn’t specified AFAIK. I can
>dig up some bugs if you’re interested in details.
I would be interested, yes. Thanks.
> On Aug 24, 2018, at 2:43 PM, Kris Maglione <kmag...@mozilla.com> wrote:
>> The tricky part with going the other direction (XUL doc, HTML elements) is that we have elements that are still XUL, and the XUL flexbox layout and CSS layouts don’t play well together. So migrating parts of the UI at a time into HTML elements is going to cause CSS/layout headaches unless if the parts can be pretty isolated from each other. I’m not sure I can describe all the problems exactly, but I’ve experienced this first hand when trying to put HTML inside XUL parents in the Inspector panel - things just don’t display correctly and the behavior isn’t specified AFAIK. I can dig up some bugs if you’re interested in details.
>
> I would be interested, yes. Thanks.
I’ve asked the frontend team if they could point me to more examples, but https://bugzilla.mozilla.org/show_bug.cgi?id=1437302#c8 and https://bugzilla.mozilla.org/show_bug.cgi?id=1259812#c16 (which resulted in https://searchfox.org/mozilla-central/source/devtools/client/themes/inspector.css#137-144) are two I found so far.
It’s possible this is doable and I just don’t know the right tricks, but AFAIK the behavior is unspecified and attempting to use it turns into spending a lot of time experimenting in the Browser Toolbox and then eventually abandoning it and using XUL elements/flexbox.
Brian