57280 - Not all entries shown on first expansion of tree (directory.xul)

Status: RESOLVED WONTFIX

(Core :: XUL, defect, P2)

Description

[Jeffrey Baker]

Tested on Linux 2000-10-19-06 Trunk build.  When viewing an FTP listing, not all
files in a directory are listed on the first expansion of that directory.  To
see all files, it is necessary to collapse and expand the directory a second
time.  To reproduce:

1) ftp://ftp.mozilla.org/pub/mozilla/nightly
2) Wait for it to finish loading (the throbber is no indicator, grr)
3) Pick a directory to expand (e.g. 2000-09-21-10-M18)
4) Click > to expand

Result: No files shown
Expected: four files and one directory shown

5) Click \/ to collapse
6) Click > to expand

Result: now all files are shown.

A fairly obnoxious bug, but with a known workaround.

Comment 1

[Jeffrey Baker]

Note please that the other workaround is to scroll the desired directory out of
view and back again, after which all entries suddenly appear.  Thus it seems to
be a tree widget reflow problem, not an FTP directory listing problem.

Comment 2

[djk]

Could this be a dup of either bug 56979 or even bug 56310?

Comment 3

[John Morrison]

Hey, Brian. We were looking at this on another bug, no? (or is this a different 
thing).

Comment 4

[John Morrison]

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

Comment 5

[John Morrison]

Tagging with rtm nomination, but when push comes to shove, this ain't gonna
make the cut. As jwbaker notes: "A fairly obnoxious bug, but with a known 
workaround."

Comment 6

[Peter Trudelle]

Workaround is easy, but it is not obvious, nor is there any indication that it
is needed.  This just appears to be insidious data loss.  rtm need info.

Comment 7

[Peter Trudelle]

Changing OS to all, since I reproduced using 102008 build on Win98

Comment 8

[Brian Ryner (not reading)]

i don't think it's 56979.  could feasibly have the same root cause as 56310.

Comment 9

[David Hyatt]

Patch attached to 57139.

Comment 10

[scalkins]

CC myself and others on this one.
This seems to affect aim as well in the buddy list.
Buddy State icons won't update till a refresh.
See Bugscape bug http://bugscape.netscape.com/show_bug.cgi?id=3016

Comment 11

[David Hyatt]

Ok, I have distilled out a small part of 57139 that fixes this bug.  So the 
whole 57139 patch is not required here.

Here it is:

Index: layout/xul/base/src/nsTreeLayout.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/xul/base/src/nsTreeLayout.cpp,v
retrieving revision 1.11
diff -u -r1.11 nsTreeLayout.cpp
--- nsTreeLayout.cpp	2000/10/17 19:00:34	1.11
+++ nsTreeLayout.cpp	2000/10/27 06:51:24
@@ -260,7 +260,7 @@
     box->GetNextBox(&box);
   }
 
-  if (group && (group == outer) && availableHeight > 0) {
+  if (group && (group == outer)) {

Comment 12

[David Hyatt]

This already has an r=bryner, since it was part of 57139.

Comment 13

[David Hyatt]

a=[e-mail]

Comment 14

[Ben Goodger (use ben at mozilla dot org for email)]

that a=[e-mail] was from me, but posted from hyatt's machine.

Comment 15

[David Hyatt]

Fixed.

Comment 16

[John Morrison]

Reopening and setting rtm-. With 2000110509 win2k, I still get a failure rate
of about 1 in 15, where the files in a directory are not shown. 

At this point, I'm not sure that this is a tree bug. It may be in necko, or 
in the datasource -- I get a pretty high correlation between threadsafe 
assertions in a debug build, and failures to show any files.

Maybe we can just sort out whether the tree has any content appended in the 
cases where these files fail to show, and see where the failure is.

Comment 17

[John Morrison]

... and this bug should be considered to be about FTP only (no AIM, no 
bookmarks, etc.).

Comment 18

[Peter Trudelle]

resolving as wontfix. Per Hyatt, multi-column trees are now unsupported, all
such trees should switch to using outliner.