XUL <tree>s are used in : - InContent prefs - about:welcomeback - about:sessionrestore - ...

In Library there also trees. And here with hundreds or more of bookmarks it needs to be fast in initial showing and scrolling.

xul tree has the advantage of lazy loading contents when they become visible, but still allocate the whole height for scrolling, without that the Library/sidebar views would not be possible. that should be part of the plan, even if not available immediately.

(In reply to Marco Bonardo [::mak] from comment #2) > xul tree has the advantage of lazy loading contents when they become > visible, but still allocate the whole height for scrolling, without that the > Library/sidebar views would not be possible. that should be part of the > plan, even if not available immediately. For gaia apps we packaged/cleaned up Roc's virtual list POC [1]. Looks like it would fit the bill nicely: * the whole height is allocated for scrolling * the memory profile is super low (the actual DOM stays small) * the "data source" can fetch the content lazily, and there's even a mechanism to handle cases where the content is "late" (ie. behind scrolling) The library can be found here [2] and there's also a a WebComponent available [3]. Of course it was developed for an APZ/Touch world and the detailed requirement might not align that well, but it'd be cool to collaborate on this :) [1] http://people.mozilla.org/~roc/virtual-list-demo.html [2] https://github.com/gaia-components/fast-list [3] https://github.com/gaia-components/gaia-fast-list

XUL trees support, well, trees - so expanding/collapsing parts of the tree. The example (1) from comment #3 seems to not be using these. The gaia component seems to support one-level nesting in the form of "section"s, AFAICT? Is that right? How hard would it be to implement a tree-type thing instead? Also, how serious is stuff like https://github.com/gaia-components/fast-list/issues/55 ?

(In reply to :Gijs Kruitbosch from comment #4) > XUL trees support, well, trees - so expanding/collapsing parts of the tree. > The example (1) from comment #3 seems to not be using these. The gaia > component seems to support one-level nesting in the form of "section"s, > AFAICT? Is that right? How hard would it be to implement a tree-type thing > instead? Ahah! Very good point. No it does not, and I'm afraid this is exactly the kind of feature where sharing the same codebase between a mobile optimized and a desktop component might get too tricky to be worth it. Oh well :) > > Also, how serious is stuff like > https://github.com/gaia-components/fast-list/issues/55 ? Getting better :)

As noted in bug 1446335, the latest plan does not involve creating a replacement of the "tree" widget in mozilla-central. While we may eventually find a use for user interface solutions like the virtual view exemplified in comment 6, this will be evaluated on a case by case basis, and will likely be implemented with new programming interfaces that don't resemble the current "tree" element. Conversely, we may also find out that we have no need for this component. I'm closing this bug because we are not considering the general idea of creating a replacement for "tree", so there is no specific effort to track here. If solutions are needed for individual components, we will file new bugs accordingly.

Sad to hear that Mozilla is not considering making HTML a mature language for specifying UI. Application designers should therefore better move to other ways of doing UI.

Robert, knowing you I'm a bit surprised to see comment 8. There is a big difference between making HTML a mature language for specifying UI and implementing specific UI components ourselves. While the latter can inform the former, which I think is what you're implying here, I don't think the "tree" element as implemented in XUL would be a good model to inform our platform decisions. In fact, we could argue that by being deliberate in not spending time on a 1:1 re-implementation of a 20 years old UI model, that we don't actually need for offering a modern browsing experience, we have collectively more time available to work on platform changes that would support those use cases that are actually needed.

If we want people to write somewhat complex UI in HTML, we'll need some kind of <tree>-like widget in it. While Firefox can possibly reasonably work around it (though I think it will need sub-par choices for that), UIs like a HTML-based version of Thunderbird etc. will require something like it. Not that it has to be based on the XUL implementation at all (and there may be good reasons for not doing that), but it should take the lessons from it and possibly some ideas from its implementation choices that make huge lists still perform decently. The current implementations of large lists and tree-like structures on HTML-based UIs are a huge mess right now and in most cases buggy, not working well with a11y, and clumsy to work with. If Mozilla doesn't care for helping to invent a solution in the HTML standards for that and a well-performant one at that, the impression in the HTML authoring world will continue to be that Mozilla is only following (with huge delays) what others create, and not that Mozilla is leading innovation - which is what bothers me most on all this.

(In reply to Robert Kaiser from comment #10) > If we want people to write somewhat complex UI in HTML, we'll need some kind > of <tree>-like widget in it. While Firefox can possibly reasonably work > around it (though I think it will need sub-par choices for that), I would suggest the Firefox options user interface is a perfect example of a user interface that needed a tree and is sub-par without one. What is there not is spaghetti options. Unless you know they are there there is little help from the user interface in narrowing what you are looking for. It is probably ideal for rubbing your finger on the glass, flicking up and flicking down while you try and locate the preference you want in a long list that is limited to the screen size of your phone.

@Paolo, we don't need an exact 1:1 replacement of the XUL <tree> API. In fact, there are probably much better ways to specify tree items. But the UI component itself is indeed needed, as can be see in Thunderbird thread pane, folder pane, Firefox bookmarks, Firefox history, and other places. Important are: * Fast enough for up to 1 million entries * tree: hierarchical entries with expander * table: multiple columns, sortable, configurable (including the combination of tree and table, see Thunderbird thread pane) * Comfortable API There have been various attempts of creating tables, trees or similar widgets in HTML and JavaScript, but there is no single implementation that fulfills all the first 3 requirements at the same time. It's not because there is no need - as the number of failed attempts shows, but that it's hard to implement right. XUL <tree> was implemented in C++ for a reason. My fastlist was an attempt to do that in JS, but just a prototype for now. This widget is a basic UI component needed for applications. The lack of this kind of basic functionality seriously limits application UIs written in HTML.

This is quite simply a requirement for Thunderbird. If the XUL <tree> is removed from mozilla-central, and there is no suitable replacement that meets the above minimum requirements, Thunderbird is dead. Given that there is talk about removing XUL <tree>, we are proposing to start writing a replacement now. Those who remove existing functionality have the burden of coming up with a suitable replacement.

Rephrasing the last comment, I mean we would like to work together on creating a replacement, *within* the Mozilla project, given that we need the widget. That's what this bug was about.

(In reply to Ben Bucksch (:BenB) from comment #12) > But the UI > component itself is indeed needed, as can be see in Thunderbird thread pane, > folder pane, Firefox bookmarks, Firefox history FWIW, history is exactly the kind of case where I hope we'll stop using a tree, it makes things worse. I think the global idea of "don't just reimplement <tree> and replace consumers blindly, but rather evaluate on a case basis if they really need a tree" makes a lot of sense. And I suspect in the end it will end up filing a new bug to implement a hierarchical view. We'll very likely need that widget for bookmarks, it won't have to be the same as <tree>, it could be completely different, we don't know yet. As far as I understand, this won't happen overnight, so there's no reason to panic, yet.

(In reply to Ben Bucksch (:BenB) from comment #12) > @Paolo, we don't need an exact 1:1 replacement of the XUL <tree> API. In > fact, there are probably much better ways to specify tree items. But the UI > component itself is indeed needed, as can be see in Thunderbird thread pane, > folder pane, Firefox bookmarks, Firefox history, and other places. > > Important are: > * Fast enough for up to 1 million entries If you really have 1M entries at once, then it might be worth looking at techniques like lazy-loading/infinite scrolling, rather than actually trying to create something that displays 1M entries. > * tree: hierarchical entries with expander > * table: multiple columns, sortable, configurable > (including the combination of tree and table, see Thunderbird thread pane) > * Comfortable API You might want to consider looking at the different tree implementations in DevTools, which use React.

> "evaluate on a case basis if they really need a tree" makes a lot of sense. Thunderbird thread pane needs all of the above. That's why I mentioned it. > If you really have 1M entries at once, then it might be worth looking at techniques like lazy-loading/infinite scrolling That's what my prototype in comment 8 does, yes. This bug is about developing this into a form that's usable by an application like Thunderbird for the thread pane.

> That's what my prototype in comment 8 does, yes Sorry, comment 6.

For reference, the bug for the removal of XUL <tree>: bug 1446335.

In light of bug 1446335, please reopen this bug here. With bug 1446335, and without a replacement (this), Thunderbird will simply be dead. There are 25 million users hanging off this bug here.

(In reply to Ben Bucksch (:BenB) from comment #20) > In light of bug 1446335, please reopen this bug here. With bug 1446335, and > without a replacement (this), Thunderbird will simply be dead. There are 25 > million users hanging off this bug here. DevTools provide a React-based TreeTable widget that provides lazy loading. TB can work on extending that widget to support resizing and sorting. Sorting might be something DevTools will implement for the Storage inspector. https://dxr.mozilla.org/mozilla-central/source/devtools/client/shared/components/tree Alternatively, TB can also start investigating alternative UIs to the tree table.

(In reply to Tim Nguyen :ntim from comment #21) > DevTools provide a React-based TreeTable widget that provides lazy loading. > TB can work on extending that widget to support resizing and sorting. > Sorting might be something DevTools will implement for the Storage inspector. > > https://dxr.mozilla.org/mozilla-central/source/devtools/client/shared/ > components/tree I don't know much about react/react-dom, but if it needs to create real DOM before the tree is rendered then I would be worried about performance in Thunderbird. I remember when Mailnews used the old tree widget which did exactly the same. It was creating DOM lazily and the performance was terrible. David Hyatt then started working on a new widget - outliner which became the new tree widget. At the time I implemented the connecting lines, a content view for the tree widget, so the widget could be backed also by real DOM (suitable for not very big trees) and some other features. I just want to say that I remember all the history. DOM and layout is faster these days then it was 15 years ago, but I guess big tress will always need special (native) handling.

This was originally filed as a Firefox bug, and in my opinion comment 0 and the bug subject are currently framing the problem in restrictive terms. This bug doesn't reflect the current thinking in Firefox, and it's unclear to me if the discussion about Thunderbird should also be framed in the same terms, so for the latter I filed bug 1446341, giving it a title that defines the problem while leaving the solution open to more interpretations. If it turns out that a "tree" replacement is wanted, compared to other approaches like adopting the existing "tree" widget code, it may make sense to move this bug or file a new one in the Thunderbird product.