Closed Bug 51833 Opened 23 years ago Closed 23 years ago
Expanding tree folders sometimes causes lower-down folders to not paint
45.27 KB, image/jpeg
46.04 KB, image/jpeg
27.20 KB, patch
|Details | Diff | Splinter Review|
This is the current patch for tree fixes. It touches nsIPresShell so make sure you do a depend build from the top.
47.95 KB, patch
|Details | Diff | Splinter Review|
I'll send two pics. My system is redhat 6.2 with newest updates.
when reporting a bug, please specify build number. Probable dupe of 51814. Investigating...
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
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking
Ever confirmed: true
maybe a tree problem.
Assignee: asa → gagan
QA Contact: doronr → tever
Assignee: gagan → rjc
Tree display problem, over to hyatt
Assignee: rjc → hyatt
nsbeta3+, P3 for M18
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 ftp://ftp.netscape.com/pub/netscape6/ 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?
Status: NEW → ASSIGNED
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 available.
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 workaround.
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
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.
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 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
No longer depends on: 54049
Resolution: --- → DUPLICATE
verified duplicate (and fixed [in general] -- they are a few ftp edge cases already filed).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.