1446335 - [meta] Remove the XUL "tree" widget

Status: NEW

(Core :: XUL, task, P5)

Description

[:Paolo Amadini]

As part of the architectural efforts to remove XUL from mozilla-central, we are looking into deleting the "tree" widget entirely.

While this removal will not happen very soon, the eventual plan of record does not involve developing a replacement that provides the same user experience. Instead, each of the current uses of "tree" in mozilla-central will be evaluated independently and replaced with an alternative that works for the specific use case.

The consumers that use the most features of "tree" in mozilla-central are the Library window and the sidebar of Firefox. There are ongoing investigations to move these to a different user interface model. This would be a major project, and once it is completed, it may get rid the most complex dependency we have for removing "tree" from mozilla-central.

In the meantime, we will start by removing other uses to see if there is anything obvious we may have missed in the analysis of the current consumers.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Does Thunderbird have a plan to replace its tree usage?

Comment 2

[:Paolo Amadini]

We don't know at the moment, there is bug 1446341 on file.

The removal of "tree" will not happen very soon, and it may occur shortly before we remove all of XUL from mozilla-central. At that point, we will have a clearer picture of whether Thunderbird plans to migrate away from XUL entirely or adopt some of its features.

Comment 3

[Ben Bucksch (:BenB)]

XUL <tree> is completely central to Thunderbird's UI. The XUL <tree> was originally implemented specifically for Thunderbird, and with the needs of Thunderbird in mind. The folder pane and the thread pane are XUL <tree>s, and the thread pane is the most prominent UI of Thunderbird.

It is highly complex and needs:
* Fast enough for up to 1 million entries
* tree: hierarchical entries with expander
* table: multiple columns, sortable, configurable
* the combination of tree and table at the same time
Without XUL <tree>, and without a suitable replacement that at the very minimum does all of that, (and of course more that is too extensive to discuss here),

***Thunderbird will simply be dead.***

This is why I asked bug 1183812 to be fixed. This will not be trivial, and won't be done in a weekend. I've already looked, and there's nothing out there that even comes close. This is a 6-12 months project with full time staff, given that so much of Thunderbird hangs off it. We need a suitable replacement that meets all requirements of Thunderbird, *before* XUL <tree> is removed. Otherwise the project is dead. Note that Thunderbird has 25 million users. I don't think it's worth it.

Comment 4

[Ben Bucksch (:BenB)]

Paolo: I understand that this is just a placeholder and you don't have a timeline yet. But this needs a concerted effort to create a replacement, and is a large project on its own. If you want the Thunderbird project to handle this, we'd need 2 years of ahead warning time, and funds to create the replacement, and need to build a development team for it etc..

Comment 5

[:Paolo Amadini]

This is a tracking bug for the removal of the "tree" widget from mozilla-central. We can continue to discuss the Thunderbird picture in bug 1446341, where I just commented with some considerations and suggestions.

Comment 6

[Firefox Bug Husbandry Bot]

Moving to Core:XUL per https://bugzilla.mozilla.org/show_bug.cgi?id=1455336

Comment 7

[Mats Palmgren (inactive)]

Attachment: Simple tree using grid layout

This is a mockup of a Grid layout that could be used for simple cases of XUL trees like for example the History Sidebar etc.

Comment 8

[Tim Nguyen :ntim]

(In reply to Mats Palmgren (:mats) from comment #7)

Created attachment 9200156 [details]
Simple tree using grid layout

This is a mockup of a Grid layout that could be used for simple cases of XUL trees like for example the History Sidebar etc.

Thanks! This solves the layout bit in a way that can be integrated in custom elements (since it keeps the DOM structure). Unfortunately, there are other bits too:

Basic things that would need to be taken care of:

• ability to select rows
• rewriting styling (:-moz-tree-* pseudos)
• porting XULTreeAccessible, this relies heavily on the layout frames, but I guess the CE can set the right aria roles if we used DOM elements.
• porting nsITreeSelection/nsITreeView usages: the whole tree CE relies on these for keyboard navigation, handling clicks, populating content and other things. This will probably need a better API to be more suited for real DOM elements.
• potentially perf (notably for bookmarks/history stuff)

There are more specific features too, that only certain places use:

• context menus (I think only the places-tree derived CE uses those, so it could be generated there)
• resizable columns (this can probably be done with some listeners that change the grid-template-columns or simply go away)
• checkbox cells, these are used mostly in <richlistbox> style usages (zero-depth), in about:preferences mainly
• editable cells (afaik only the search engine tree in about:preferences#search use them): that tree could potentially re-use the "Add new engine" dialog, but in an editing state
• reordering/dropping rows (for bookmarks)
• <treecolpicker>: allows showing/hiding columns, but not sure that's really important.

Overall, given the complexity of trees, a lot will need a rewrite. So it's worth looking closely at what feature set the replacements would have. The prototype is well suited for tree-table type things, but most usages are either trees or tables, so rewriting them may be faster.

Though, one thing that could be sorted out now is maybe making <treecol> use CSS grid when it's not inside a <tree> (many places do that).

Comment 9

[Brian Grinstead [:bgrins]]

(In reply to Tim Nguyen :ntim from comment #8)

(In reply to Mats Palmgren (:mats) from comment #7)

Created attachment 9200156 [details]
Simple tree using grid layout

This is a mockup of a Grid layout that could be used for simple cases of XUL trees like for example the History Sidebar etc.

There are more specific features too, that only certain places use:
...
Overall, given the complexity of trees, a lot will need a rewrite. So it's worth looking closely at what feature set the replacements would have. The prototype is well suited for tree-table type things, but most usages are either trees or tables, so rewriting them may be faster.

Yeah, something like this wrapped up in a Custom Element looks like a nice solution for simpler trees. For Places and more complex consumers, writing a drop-in API replacement seems unlikely. To take Places as an example, I'd want to start with some analysis of design & product requirements - how can users be most successful finding history & bookmarks & what features are needed to help with that? Then some combination of rewriting the consuming code and pulling out shared functionality where possible, especially in areas that are hard & xul tree is uniquely good at like perf.