When you have a XUL tree nested inside more than 1 scrollable view the row selection in the tree can go wrong. If any of the outer views are scrolled and you then try to select a row in the tree you will end up selecting a row other than the one you wanted. This is due to the layout code not taking into account the offsets of the outer, enclosing, views. Also see 147806 for a similar issue with XUL pop-ups.

This seems like a recuring issue in multiple places, which we've hit (twice so far) becuase we have nested scroll views. Could this logic not be pushed out of the various components and into the view manager, which could handle walking up the view heirarchy resolving for scroll offset (and any other position changes)? I.e a GetCombinedOffset on nsIView or similar.

taking

could you attach a test case please ?

The first box can be scrolled and rows in the tree selected quite happily. In the second box, however, row selection breaks down if the outer box is scrolled. If the outer box is not scrolled tree selection works fine - even if the inner box is scrolled. What appears to be happening is that the offset of the outer scroll has not been taken into account when calculating the selection point in the tree. This file requires test.css.

column picker is wrong positioned too cc'ing roc

Any chance of getting this in? (See comments in #147806 too..)

Comment on attachment 107013 [details] [diff] [review] Updated version of the patch that applies against the trunk It looks good. I assume you didn't notice any regressions. r=varga

You need to go up only to the root view for this document. If you just check against null, you may find yourself going up into parent documents if your XUL is in an IFRAME or something. See nsMenuPopupFrame::GetViewOffset for code that does this. Other than that, looks OK.

No discussion for THREE YEARS, but the bug persists.

I think I triggered a similar (or the same) bug w/ a scrollable tabpanel. Should I report a new bug or just post details under this bug?

never checked in?