954563 - Listbox sometimes does not display all list items after scrolling

Status: RESOLVED WORKSFORME

(Instantbird Graveyard :: Conversation, defect)

Description

[Instantbot]

*** Original post on bio 1130 by Kevin Gadd <kevin.gadd AT gmail.com> at 2011-11-01 04:14:00 UTC ***

*** Due to BzAPI limitations, the initial description is in comment 1 ***

Comment 1

[Instantbot]

Attachment: Screenshot

*** Original post on bio 1130 as attmnt 966 by kevin.gadd AT gmail.com at 2011-11-01 04:14:00 UTC ***

I left the participants list in an IRC channel collapsed for a while and it desynced severely. At this point, the list of users does not update at all no matter what happens, but the Participants: N counter updates. I've attached a screenshot where the list shows maybe half the users in the chat (compared with the counter). At this point I left the list uncollapsed and signed in another client, and the chat scrollback clearly showed the join event but the list did not update.

Unclear on precise reproduction steps since I tend to leave my client running for a long time, but my guess is it's from collapsing the list panel.

Comment 2

[Patrick Cloke [:clokep]]

*** Original post on bio 1130 at 2011-11-01 11:52:29 UTC ***

A couple of the developers have tried to reproduce this and haven't been able to.  After this happens, do you see any errors in the error console (Tools > Error Console) that might seem related? If you come across precise reproduction steps, please let us know!

Comment 3

[aleth [:aleth]]

Attachment: Reproduction screenshot

*** Original post on bio 1130 as attmnt 967 at 2011-11-01 16:07:00 UTC ***

I can confirm there is a bug here, after leaving #extdev open for a while. I am not sure it is linked to collapsing the participant list however. It could just as much be linked to rapid scrolling of the participant list (I did it via the mousewheel) - see screenshot and comments therein. Note no participants are lost (which after all seems impossible from the code since the participant count is always correct): after a slower scroll, some participants 'return' and on scrolling through the whole list via the keyboard, they are all displayed.

Comment 4

[aleth [:aleth]]

*** Original post on bio 1130 at 2011-11-01 16:09:26 UTC ***

(Changing status to NEW)

Comment 5

[aleth [:aleth]]

*** Original post on bio 1130 at 2011-11-01 16:12:12 UTC ***

Just to note rapid scrolling via scrollbar is just as effective to reproduce; and I am almost certain it is not linked with collapsing the list, but somebody else should confirm.

Comment 6

[aleth [:aleth]]

*** Original post on bio 1130 at 2011-11-01 16:22:04 UTC ***

I have now also got into a situation where even via keyboard it is not possible to regain the entire list: pressing "Home" or scrolling up past the first displayed item, the selection bar simply disappears (as the selected item is not being displayed). Collapsing/reopening the list makes no difference btw.

Using DOM Inspector, there is no difference in applied rules between listitems which are displayed and those that are not. However, items which are not displayed have Position and Dimensions set to 0 (available via Box Model tab).

Is this likely to be a mozilla bug?

Comment 7

[aleth [:aleth]]

*** Original post on bio 1130 at 2011-11-01 16:34:06 UTC ***

FWIW A workaround to get the whole list back is to put the chat on hold and then reopen.

Comment 8

[Florian Quèze [:florian]]

*** Original post on bio 1130 at 2011-11-01 17:53:35 UTC ***

Are you sure the issue discussed from comment 2 to comment 6 is related to what's described in comment 0?

I've frequently observed the issue you (aleth) describe with the scrollbar although not with such a dramatic effect (I've only been able to reproduce when the list has a lot more participants, typically 1000+ on #ubuntu). I'm almost sure it's a Mozilla bug (although I don't know if it has ever been filed in Mozilla's bugzilla; and filing it without a minimized testcase didn't seem very useful to me).

However, when this issue occurs, the end of the participant list is not displayed, whereas on Kevin's screenshot, the list seems to also have nicks for the end of the alphabet.

Comment 9

[aleth [:aleth]]

*** Original post on bio 1130 at 2011-11-01 18:12:17 UTC ***

I have also reproduced it with the top of the list going missing and the end being correct. And even on the screenshot I posted, you can see the first few listitems are originally missing. 

So to me it does look like exactly the same issue. 

However it does appear so far that what goes missing is always the beginning or end of the list, not random elements from the middle.

Comment 10

[aleth [:aleth]]

*** Original post on bio 1130 at 2011-11-01 18:38:46 UTC ***

Just to add that while I have reproduced the problem more than once, I can't reliably do so. So there might be something missing from the picture beyond 'scrolling'.

Comment 11

[aleth [:aleth]]

*** Original post on bio 1130 at 2011-11-03 23:59:19 UTC ***

See also bug 954576 (bio 1143) for another possible cause of the original bug report.

Comment 12

[aleth [:aleth]]

*** Original post on bio 1130 at 2012-01-16 20:23:56 UTC ***

I have now also observed this behaviour in the log viewer log selection listbox (for an IRC channel with many logs), on scrolling via scrollbar.

Comment 13

[aleth [:aleth]]

*** Original post on bio 1130 at 2012-02-04 23:00:45 UTC ***

Filed as https://bugzilla.mozilla.org/show_bug.cgi?id=724314

Comment 14

[aleth [:aleth]]

*** Original post on bio 1130 at 2012-06-28 00:08:18 UTC ***

So, I decided to take another look at this, and happily since Gecko 13 it is

1) *much* harder to reproduce (though not impossible)

2) The behaviour has changed in that items no longer seem to go missing. Instead what we see is the last few items and blank space underneath. The scroll position is incorrect in the sense that if we scroll upwards using the keyboard, the selection disappears off the screen without the listbox scrolling. Using the mouse it is easy to test with.

3) Therefore, the listbox recovers as soon as we scroll again with the mouse

4) DOM Inspector suggests listitems are now bound correctly when they are bound dynamically.

This seems good enough :)

I couldn't find the change in the code which fixed this, so while I am resolving this bug, it may need to be reopened as I don't know why it now works.

Comment 15

[aleth [:aleth]]

*** Original post on bio 1130 at 2012-06-28 00:15:11 UTC ***

(In reply to comment #13)
> I couldn't find the change in the code which fixed this, so while I am
> resolving this bug, it may need to be reopened as I don't know why it now
> works.

In particular, it would be great if the bug reporter could confirm this (using the current nightly build) ;)