Overview Description: Another situation where rows are not repainted in a <tree>. Just cataloguing this one separately, to avoid confusing the other various bugs that apply to trees, etc. 1) Create a new profile (just so you have no prior persisted information about which folder should be open) 2) Go to ftp://ftp.mozilla.org/pub/mozilla/ 3) Open these top-level folders: brownbag contrib l10n libraries nightly 4) Ensure that the browser content area is short enough vertically that a scrollbar is now showing (e.g. the distance between 'brownbag' and 'nightly' is greater than the height of the viewport). 5) Click to put the selection on 'nightly' 6) Arrow down to move the selection down 10 subfolders. This should cause a scroll to occur as the view tracks the selection 7) Arrow up to return the selection to 'nightly' 8) Arrow left on 'nightly' to collapse the nightly folder Actual results: When you press the left arrow, the top 8 or 9 rows of the screen (subfolders of 'brownbag') will not be repainted. (However, if you force a paint, they do reflect the correct contents, and the scrollbar is not out of synch. This situation is fully recoverable, and is not a crash situation, to my knowledge.). Expected results Er, those rows should be painted. (stating the obvious). Reproducibility: 100% in this build. Build Date & Platform Bug Found: win2k debug trunk build plus hyatt's patch from bug 57139 (trunk build pulled 11:30pm Friday Oct 27th night) (Note: no assertions occurred in the debug build for this steps to reproduce.). Note: I couldn't seem to find an analogous situation is mailnews or the bookmark manager.
By the way, you can reproduce this when using the mouse, instead of arrow keys. The key is to open the nightly folder, move the view down, then collapse the nightly folder again.
jrgm, is this fixed by the patch in 57139?
Status: NEW → ASSIGNED
No, this was in a build that included that patch for bug 57139. (In the current candidate build on win2k, doing these steps -- the result is a much, much worse situation -- the top 8 or 9 rows, and the bottom 8 or 9 rows are blank, not just unpainted (they are dead rows). The behaviour with this patch is much better than the current behaviour (and really isn't a new bug, it's just something that needs future love)).
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WONTFIX
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.