[meta] Stop extending a table for the tree-view
Categories
(Thunderbird :: General, task, P3)
Tracking
(thunderbird_esr115 wontfix)
| Tracking | Status | |
|---|---|---|
| thunderbird_esr115 | --- | wontfix |
People
(Reporter: aleca, Unassigned)
References
(Blocks 2 open bugs)
Details
(Keywords: meta)
Attachments
(1 file)
Using an HTML Table element for the initial TreeView implementation has been very beneficial since it allowed us to inherit the elastic resizing of columns.
We reached a point where the DOM reflow performance is affected by the table structure.
Now that we have many tests and good performance for the current widget, we can explore its rebuild with simple divs.
| Reporter | ||
Comment 1•2 years ago
|
||
| Reporter | ||
Comment 5•1 year ago
|
||
Geoff, Martin, what do you think about this?
Is this worth pursuing this maybe around Q4 this year or we don't have any more performance and DOM rendering concerns about extending a table?
The WIP patch I attached is a proof of concept to confirm the possibility of having the columns resizing feature behaving properly and it seems to work.
Comment 6•1 year ago
|
||
My gut feeling is that it's probably better in the longer term, as the table layout is the exception for the usage of that widget, and other more list but with freeform data contents usages grow. It not being a table will also make it so we don't have to deal with some annoying quirks of tables when we're doing things that aren't really tables.
I do wonder what exactly the impact is for assistive technologies though. (It might be better there too?)
| Reporter | ||
Updated•1 year ago
|
| Reporter | ||
Updated•1 year ago
|
Comment 7•1 year ago
|
||
I'd like to at least try a version where the rows are absolutely positioned <div>s, with the vertical position set by either top or transform: translate. That should mean the rest of the page's layout is not dependent on the size of the rows, and the rows' positions are not based on the positions of their neighbours.
That was the plan originally but we went down a different route when column sizing got complicated. Let's revisit it.
Comment 8•5 days ago
|
||
This bug has had no dependent bugs for a long time, despite a meta bug.
This is the last dependent bug for bug 1724841.
I suppose it's time to close or fix it.
Comment 9•5 days ago
|
||
(In reply to Takanori MATSUURA from comment #8)
This bug has had no dependent bugs for a long time, despite a meta bug.
That doesn't mean there's nothing to do, it's just not been planned so far.
This is the last dependent bug for bug 1724841.
Same there, we still have a couple of XUL trees in our code base, see https://searchfox.org/comm-central/search?q=%3Ctree+&path=&case=false®exp=false (though you can ignore the results in mozilla/ and suite/ for the purposes of that meta bug).
| Reporter | ||
Comment 10•5 days ago
|
||
Thanks for the ping.
As Martin said,t he XUL tree is still present in our code base and we're slowly removing it.
Converting our new Tree widget into divs is not an easy task, and the past performance improvements really made the new widget extremely reliable.
We will get to this, but there's not rush as it's not a blocker, nor it's impacting negatively the application.
Description
•