Closed Bug 51833 Opened 24 years ago Closed 24 years ago

Expanding tree folders sometimes causes lower-down folders to not paint


(Core :: Networking, defect, P2)






(Reporter: tapio.piironen, Assigned: bryner)



(Keywords: regression, Whiteboard: [nsbeta3-][PDTP2] [rtm+ need info])


(4 files)

I'll send two pics.
My system is redhat 6.2 with newest updates.
Attached image And after
when reporting a bug, please specify build number.

Probable dupe of 51814.

confirmed... something is definatly going on with ftp. see also bug 51814, which
says during initial load, directories are missing... i didnt notice this
behaviour, myself.

note that the files dont actually disapear! if you click where they should be,
they highlight and are drawn again.

over to networking... good luck.
Severity: normal → major
Component: Browser-General → Networking
Ever confirmed: true
Keywords: regression
maybe a tree problem.
Assignee: asa → gagan
QA Contact: doronr → tever
Assignee: gagan → rjc
Tree display problem, over to hyatt
Assignee: rjc → hyatt
Keywords: nsbeta3
nsbeta3+, P3 for M18
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18
Reproduced on WinNT also, OS->All.
OS: Linux → All
Hardware: PC → All
Assignee: hyatt → bryner
I think this has to go to nsbeta3- tomorrow.
I'm not sure if this can go to b3-. FTP on Linux is undependable right now.

bryner: here's one manifestation:
1) go to
2) there are five folders. Starting with the bottom folder, quickly open
   each folder (which seems to kick off an asynch) load. When each folder
   loads, it winds up painting where it currently thinks it should be, without
   regard for the other folders. After that, the visual appearance is way out
   of synch with the logical model.
Yes, I'd like to push this up to P2.  Can we do that?
We can cover it tomorrow with Peter, but I think this must be fixed. I can also
reproduce this on Windows on occasion. 

By the way, bryner, do you think that if the 'spinner' image had the same pixel
height as the other images, this problem would be less severe (if not entirely 
solved). As it stands right now, when the spinner kicks in, it causes all the 
row heights to increase by 2px. (There is this bug (bug 45341) which does point
out that all icons in trees should have a uniform height to avoid this dynamic
row-height resizing). 
Yes, I noticed that too, and I think that might help.  I can't reproduce this on 
any other trees [than ftp], coincidentely, no other trees have a spinner image.

As for the actual cause, it seems that for some reason we are failing to lay out 
all of the items in the tree.  We seem to lay out items down to either the same 
number of rows the tree had prior to expanding the node, or down to the bottom 
of the children of the open node.  FTP is adding kids to the node as they are 
read (or so I hope), which means we need to relayout at least from that point to 
the bottom every time a child is added.  In other words, this could be a deeper 
issue with trees when a node is expanded and all the children aren't immediately 
Unfortunately, the spinning load icon isn't the culprit.  I tried commenting out 
that css rule and still see the disappearing directories.
Bumping to P2 after discussion with QA lead, since this manifests itself 
insidiously as apparent data loss.  Users are unable to tell that the listing 
has been truncated, and will therefore have no reason to try to use a 
Priority: P3 → P2
Unfortunately, no progress on this thusfar...
PDT agrees P2
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP2]
I just witnessed this same problem in mail when loading a list of folders from
the server.  Attempting to update summary to more accurately describe the problem.
Summary: FTP View bugs sometimes → Expanding tree folders sometimes causes lower-down folders to not paint
mass-adding rtm keyword to all open nsbeta3+ xptoolkit bugs
Keywords: rtm
Bummer, but I don't think it's bad enough to hold PR3 for, especially if no fix 
is imminent. Marking nsbeta3-
Whiteboard: [nsbeta3+][PDTP2] → [nsbeta3-][PDTP2]
*** Bug 49252 has been marked as a duplicate of this bug. ***
rtm+ need info.  Worth spending a bit more time on to come up with a simple/safe
fix.  Will have to '-' if that is not possible soon.
Whiteboard: [nsbeta3-][PDTP2] → [nsbeta3-][PDTP2] [rtm+ need info]
cc'ing eric.. he's probably more on top of how to fix this than anyone right now.
Here's some status based on discussions with evaughan and hyatt:

This problem is essentially a result of the tree widget constructing frames from
inside its Layout() method.  This causes the containing Box to not be aware of
the tree's new bounds, and not paint the entire area.

evaughan has written some code to move frame construction outside the Layout()
method.  This is a fairly major change (although it is, without question, the
Right Way to do it).  I've been running with it in my tree for awhile and have
noticed no adverse effects, and this code also apparently optimizes the region
that the tree paints during scrolling.  I think we should definitely evaluate
this change, but not without thorough testing.  I'll attach his patch to this bug.

We've also investigated some quick-fix options for the immediate problem.  None
have been found so far that don't cause a negative performance hit on scrolling.
Depends on: 54049
What's up with this bug?  It has been a week since the last patch was attached.
 Does it fix the problem, without regressing performance or anything else?  Any
reason it hasn't been reviewed?  May be too late for this already.
This looks (to me) like it is the same (or almost) patch that Eric has checked
into the trunk for bug 54049 "folder pane, thread pane and Buddy list often 
fails to refresh" -- it's the uber-tree-patch which is now rtm++ this evening.

As far as the original problem report for this bug, this problem does not 
appear in the mac/linux/win32 trunk builds in FTP directories, or in other 
tree widgets as far as I have seen. 

(There does appear to be a problem in getting new content displayed in the tree 
for an FTP listing, which is independent of the tree display glitches -- 
whether the breakdown occurs in the tree, or in RDF, or in Necko would best be 
investigated as a separate bug, one which won't make RTM).
This does not look like the same patch, although there is a lot of overlap. Are
they intended to both go in?  Has one superceded the other?  What is the plan
here?  I must say, the very idea of a huge 'uber-patch' for 'tree fixes'
(plural) is quite scary at this stage in the release.
Marking dup.  This is one and the same as bug 54049, and the fix attached to
that bug will fix this as well (and the patches attached to this bug are a
little dated).

*** This bug has been marked as a duplicate of 54049 ***
Closed: 24 years ago
No longer depends on: 54049
Resolution: --- → DUPLICATE
verified duplicate (and fixed [in general] -- they are a few ftp edge cases
already filed).
You need to log in before you can comment on or make changes to this bug.