Open Bug 1446335 Opened 3 years ago Updated 3 months ago

[meta] Remove the XUL "tree" widget

Categories

(Core :: XUL, task, P5)

task

Tracking

()

People

(Reporter: Paolo, Unassigned)

References

(Depends on 15 open bugs, Blocks 4 open bugs)

Details

(Keywords: meta)

Attachments

(1 file)

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.
Depends on: 1446339
Blocks: 1446341
Depends on: 1446351
Depends on: 1446353
Depends on: 1446356
Depends on: 1446357
Depends on: 1446359
Depends on: 1446360
Depends on: 1446361
Depends on: 1446362
Depends on: 1446367
Depends on: 1446368
Depends on: 1446369
Depends on: 1446376
Depends on: 1446378
Depends on: 1446382
Depends on: 1446384
Depends on: 1446385
Depends on: 1446388
Depends on: 1446390
Depends on: 1446393
Does Thunderbird have a plan to replace its tree usage?
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.
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.
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..
Depends on: 1183812
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.
Depends on: 1456682
Moving to Core:XUL per https://bugzilla.mozilla.org/show_bug.cgi?id=1455336
Component: XP Toolkit/Widgets: XUL → XUL
Priority: -- → P5
Depends on: 1471542
See Also: → 48912
Summary: Remove the XUL "tree" widget → [meta] Remove the XUL "tree" widget
Depends on: 1493439
Depends on: 1524782
Type: enhancement → task
Blocks: de-xul-elements
No longer blocks: war-on-xbl
Depends on: 1524836
No longer depends on: 1524782
Depends on: 1641082
No longer depends on: 1446384

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.

(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).

(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.

You need to log in before you can comment on or make changes to this bug.