[meta] De-XBL
Categories
(Core :: XBL, task, P5)
Tracking
()
People
(Reporter: bgrins, Unassigned)
References
(Blocks 3 open bugs, )
Details
(Keywords: meta)
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.
Updated•6 years ago
|
Comment 1•6 years ago
|
||
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.
Comment 2•6 years ago
|
||
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.
Comment 3•6 years ago
|
||
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.
Reporter | ||
Updated•6 years ago
|
Reporter | ||
Updated•6 years ago
|
Comment 4•6 years ago
|
||
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.
Comment 5•6 years ago
|
||
Removing the support for XBL is definitely post FF60. I don't know whether FF will remove some bindings before that.
Reporter | ||
Comment 6•6 years ago
|
||
(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.
Comment 7•6 years ago
|
||
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!
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Reporter | ||
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Reporter | ||
Updated•5 years ago
|
Comment 8•5 years ago
|
||
Hi, I'm working on de-xbl for Thunderbird. I'm converting some bindings that inherit from the popup/menupopup binding, but that requires converting menupopup to a custom element (in order to inherit from it). (See bug 1531296.)
I see some menu related de-xbl bugs are in the works, but didn't see menupopup specifically. Is the plan for menupopup to just do a 1-to-1 conversion? Or something else? (I've done a quick auto-conversion, just for testing purposes so far, and it seems pretty straightforward at first go.)
Reporter | ||
Comment 9•5 years ago
|
||
(In reply to Paul Morris [:pmorris] from comment #8)
Hi, I'm working on de-xbl for Thunderbird. I'm converting some bindings that inherit from the popup/menupopup binding, but that requires converting menupopup to a custom element (in order to inherit from it). (See bug 1531296.)
I see some menu related de-xbl bugs are in the works, but didn't see menupopup specifically. Is the plan for menupopup to just do a 1-to-1 conversion? Or something else? (I've done a quick auto-conversion, just for testing purposes so far, and it seems pretty straightforward at first go.)
There isn't a bug on file yet just for menupopup. Bug 1525101 is on file to do some inherited bindings (like https://bgrins.github.io/xbl-analysis/tree/#autocomplete-rich-result-popup), but it turns out that those don't actually need to extend the "popup" binding, so we aren't implementing the MozPopup class for that one.
I think it could make sense to have a separate bug that does just menupopup alone (https://github.com/bgrins/xbl-analysis/blob/gh-pages/elements/generated/Popup.js), although we may have to do the places popups at the same time (so they don't get both CE and XBL attached). Let's move the discussion to Bug 1531296 and figure out what makes sense.
Updated•5 years ago
|
Updated•5 years ago
|
Comment 10•4 years ago
|
||
Hello, i was browsing the code repo and noticed that there are a lot of tests that declare bindings https://dxr.mozilla.org/mozilla-central/search?q=%3Cbindings+-path%3A*.rs+-path%3A*.cpp&redirect=false
Is there a bug to deal with that, now that you are almost done with regular bindings?
Reporter | ||
Updated•4 years ago
|
Comment 11•4 years ago
|
||
can be considered fixed now since we have no XBL bindings left? there's a bunch of open dependents still though, they need to retriage perhaps?
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Comment 12•4 years ago
|
||
(In reply to alexander :surkov (:asurkov) from comment #11)
can be considered fixed now since we have no XBL bindings left? there's a bunch of open dependents still though, they need to retriage perhaps?
Yes, this has served its purpose. Let's close this one and move any follow up work into other bugs (like Bug 1566221 and Bug 1563415).
Description
•