224638 - Userlist disappears if in a channel with too few users for a scrollbar

Status: RESOLVED FIXED

(Other Applications :: ChatZilla, defect)

Description

[Sean Umphlet (nosebleed)]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031028
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031028

Occasionally when I am chatting on moznet in a channel with too few users such
that there is no scrollbar required to scroll through the list, The list of
users disappears. Channels to test this out are #bs or #thunderbird (or any
channel with fewer than perhaps say 30 users. I also notice that scrolling with
the middle-mouse button restores the userlist, (but if I change a tab and go
back to that channel tab, the list is 

Reproducible: Always

Steps to Reproduce:
1. Enter an IRC channel with only a few users
2. Note that there is no userlist

Actual Results:  
No userlist displayed

Expected Results:  
Displayed a userlist

Comment 1

[Robert Ginda]

*** Bug 224641 has been marked as a duplicate of this bug. ***

Comment 2

[Felix Miata]

I saw this on OS/2 during one 0.9.46 on 1.5 session, but never before or since.

Comment 3

[Samuel Sieb]

Did you click on a user in another channel?  The way I see to reproduce it is to
go to a channel with many users and click on a user near the bottom of the list.
 Depending on which user you click on, you will see none or only a part of the
list on a channel with few users.

Comment 4

[Thib]

Confirming Samuel's diagnosis on Chatzilla 0.9.47 [Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.5) Gecko/20031007]. Clicking on a name at the bottom
of a userlist with scrollbar causes other userlists without scrollbars to behave
as if they were the same length and scrolled all the way down (i.e. rolling the
mouse wheel makes it to come back). It takes at least two ticks of the mouse
wheel for things to return to normal. A column of "empty" names followed by the
list of actual names appears after the first tick. This behavior has been around
since at least the 1.3 milestome of Mozilla, as far as I remember, but not many
channels I'm in have long userlists so it didn't occur to me it was a consistent
bug.

Comment 5

[James Ross]

Attachment: Fixes the tree content view to correctly invalidate the rows when removed

This patch makes the tree content view use RowCountChanged to notify the tree
about the changes, instead of just invalidating it. This is turn means the
selected index is updated correctly, which fixes this bug. I'll do a patch that
makes CZ work on builds without this fix in a while.

Comment 6

[James Ross]

Damn Bugzilla.

Comment 7

[James Ross]

I think this has been fixed as part of bug 197667.