Closed Bug 1397874 (war-on-xbl) Opened 3 years ago Closed 1 year ago
We have a few bugs in flight to investigate parts of XBL removal in the frontend. Some of this is incrementally landable, but others are meant only as a way to learn more about the work that'll need to be done.
Would it be worth looking into replacing XUL's tree code with a custom element class and shadow content? I have a couple proof-of-concept pages with CSS grids, display: contents, and nested grids for the scrollable part of a tree where we could look into it at least... On the one hand, being able to expose a common element for multi-column trees would probably be nice for HTML as well, and we could remove the C++ code - in addition to considering a redesign of the API. On the other hand, it could bloat memory usage considerably: XUL trees usually don't have a lot of descendant elements (we're not supposed to have recursive treechildren/treeitem elements in the XUL DOM), and my HTML5-based approach would.
FWIW, we do have some HTML based tree views (for devtools and such), so I'd assume we'd reuse one of those if possible.
Sure, absolutely. I'm just asking if we can meet all the features of the XUL tree implementation in HTML/JS/CSS, at an acceptable cost.
Summary: [meta] De-XBL Investigations → [meta] De-XBL
I don't know what the timeline for de-xbl is, but with my Thunderbird hat on, I would very much appreciate if you could delay anything that fundamentally breaks XBL until Gecko 60. With this I mean anything that would stop Thunderbird from defining their own bindings, so basically the last bits of code before XBL is fully removed. Not asking to stop removing bindings or replacing things, just allow us to keep using our own throughout the 59 ESR cycle.
Removing the support for XBL is definitely post FF60. I don't know whether FF will remove some bindings before that.
(In reply to Olli Pettay [:smaug] from comment #5) > Removing the support for XBL is definitely post FF60. I don't know whether > FF will remove some bindings before that. Agreed about the timeline. Some bindings, which are being tracked in this bug, are currently being removed. While we await Custom Element support these are mostly focused on bindings that aren't used in m-c or bindings that can be folded into their parent's implementation. In some cases those bindings will need to move to comm-central - as is the case with the xpfe autocomplete bindings, for example.
We're happy to move over some bindings to c-c to retain support, thanks for the quick answer! Looking forward to the changes you are making as well though, I'd love to get rid of XBL in Thunderbird/Lightning as well!
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.