169196 - getFirstVisibleRow() is -15

Status: RESOLVED DUPLICATE of bug 212839

(Core :: XUL, defect)

Description

[[e-mail]]

Saw this in Chatzilla and used JS debugger to find the return value.

Comment 1

[[e-mail]]

Attachment: Screen capture of tree

Comment 2

[[e-mail]]

Attachment: Test case

I've since found a new way to (temporarily) set the first visible row to a
negative number. Steps to reproduce problem:
1. Load the test case into a window big enough not to have a scrollbar.
2. Expand the last twisty. If you have a big window,
   keep expanding the last twisty until you get a scrollbar.
3. Scroll the tree up to the top.
4. Collapse the (first) expanded twisty.

Expected results: first visible row remains 0

Actual results: first visible row briefly becomes negative.

Additional information: the tree paints -ve rows confusing the view :-(

Comment 3

[[e-mail]]

Whoops, step 3 should be to scroll the tree down to the bottom :-[

Comment 4

[[e-mail]]

Finally worked out how to reliably reproduce this in Chatzilla.

Join two channels, one with many users -> a scroll bar, one with few users.

In the channel with many users, click on a user below the first page.

Then switch to the other channel.

Result: tree screws up :-P

Comment 5

[Chase Tingley]

Attachment: possible fix?

This seems to fix the problem, although I won't try to get review on it until I
understand why.  Invalidating the scroll region when the tree collapses causes
curpos to go negative, which seems bad.  On the other hand, maxpos seems to go
negative all the time with no ill effects.  The patch changes AttributeChanged
so that curpos will never be set to less than 0 when it is being reduced to
match maxpos.

So, no guarantees that this is the right fix -- in fact, I'd bet that it's not.

Comment 6

[Chase Tingley]

This is fixed by Neil's patch in bug 212839.

*** This bug has been marked as a duplicate of 212839 ***