67092 - Mark selected treeitems with "focused" attribute when tree is focused

Status: RESOLVED WONTFIX

(Core :: XUL, defect, P3)

Description

[Joe Hewitt (gone)]

This is needed to optimize our css.  Currently, we need to use the famously
inefficient descendant selector in order to draw a border around selected
treerows when a tree has focus, like this:

tree:focus > treechildren treeitem[selected][current] > treerow

I suspect that this rule is partially to blame for the super-slow style
resolution in mail when you switch the focus amongst the 3 panes.  The way to
solve this is to mark the selected treerows with a "focused" attribute when the
tree is focused, and remove it when it's not.

I've run some tests with and without these selectors in mail, and there seems to
be a slightly perceptible speed increase without them.  It's hard to really
gauge though, since my workstation is fairly quick.

attinasi/hyatt, do you think this is even worth the trouble, or is the time to
mark all selected rows with a new attribute not any better than the algorithm
currently used to resolve a descendant selector on a large tree?

Comment 1

[Marc Attinasi]

If you can change the selector
  tree:focus > treechildren treeitem[selected][current] > treerow
to
  tree:focus treerow[focused]

then you will make style resolution much faster, for sure. I have no idea what
it takes to set and clear the "focused' attribute on the treerow, however, so it
is unclear if this is a net win or not. The problem with the selector matching
algorithm is that it tries to match from the bottom up, so you pay the price of
the selector matching on all treerows (until the matching fails anyway). Marking
each treerow will only affect the currently selected and deselected rows, right?

Comment 2

[David Hyatt]

I am not sure this needs to be done.  My profiles of focusing the tree revealed
the problem to be more with pseudo matching than with the > selectors.  I think
it would be more accurate to have a bug with the summary "Focusing trees in
mail/news is slow", and then we can profile and discuss the various options.

Comment 3

[David Hyatt]

The cost can also vary based off of what's being blurred.  You're switching
between two objects usually, and so you have to consider that you're potentially
doing style re-resolution on two trees, not one.

Comment 4

[Joe Hewitt (gone)]

The problem I was referring to isn't with the ">" child selector, it's with the
" " descendant selector -- have you noticed any slowdown with regard to this
selector?

Comment 5

[David Hyatt]

Not really, since the descendant selector only occurs to the left of selected
tree items.  If you can whip this up to experiment, though, it might be worth
trying.

I'm just nervous about it, because in the case where you have all your messages
selected, you could be setting thousands of attributes on a focus.  THere is a
point at which the cost of setting a bunch of attributes far outweighs the cost
of crawling up only in the selected row case.

Comment 6

[Joe Hewitt (gone)]

don't think this will be necessary