Closed Bug 54049 Opened 25 years ago Closed 25 years ago

folder pane, thread pane and Buddy list often fails to refresh

Categories

(SeaMonkey :: MailNews: Message Display, defect, P3)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: sspitzer, Assigned: eric)

References

Details

(Whiteboard: [rtm++] PDT please review)

Attachments

(3 files)

screen shot of the folder pane in the "un-refreshed" state
68.86 KB, image/jpeg
Details
Fix
47.96 KB, patch
Details | Diff | Splinter Review
Patch with hyatt's corrections.
46.47 KB, patch
Details | Diff | Splinter Review
I've got enough accounts and folders in my folder pane so that I get a scroll bar. often, I scroll down and click on what I think is one folder or newsgroups, but when the selection happens, it's the wrong folder. if I force a repaint, everything looks ok. I also see "blank" regions at the top of my folderpane when I scroll down. I'll get a screen shot. this has been happening for a while on the WINNT build.
reassigning to hyatt. I'm pretty sure this is the state I get into before the crash talked about in 53858.
Assignee: putterman → hyatt
I've got a good screen shot. this happens frequently enough, I'm marking it at dogfood / nsbeta3. in the screenshot, notice the blank region at the top and notice that n.p.m.ui appears as a chil of "Local Folders". upon repaint, it is a child of news.mozilla.org
marking it nsbeta3, but not dogfood yet.
Keywords: nsbeta3
I'll take this bug as QA-assign-to
QA Contact: esther → fenella
Yay. More wonderful fallout from nisheeth's async reflow. At least I think I know how to fix this one.
Status: NEW → ASSIGNED
Keywords: rtm
*** Bug 53601 has been marked as a duplicate of this bug. ***
adding selmer to the cc list and mailtrack to the keywords. selmer: this is the bug I mentioned at our meeting.
Keywords: mailtrack
marking rtm+, but 'need info' until we have a fix ready to land. cc jrgm
Whiteboard: [rtm+ need info]
*** Bug 54541 has been marked as a duplicate of this bug. ***
adding to summary. the thread pane does this too.
Summary: folder pane often fails to refresh → folder pane (and thread pane) often fails to refresh
seen on mac commercial branch build 2000-09-29-11-MN6 chnaging platform to all
OS: Windows NT → All
Hardware: PC → All
*** Bug 54212 has been marked as a duplicate of this bug. ***
seeing this in the trunk as well with wi32, linux and mac mozilla builds.
Eric is working on this.
Assignee: hyatt → evaughan
Status: ASSIGNED → NEW
This affects aim as well. Some buddies/groups in the buddy list may disappear and need to be refreshed while scrolling.
Summary: folder pane (and thread pane) often fails to refresh → folder pane, thread pane and Buddy list often fails to refresh
pls remove 'need info' when you have attached patch, and reviewers have put a=/r= into this bug report.
note that all trees are suffering from this bug e.g. some of the dupes bug 53626 via bug 53601 are browser examples (Manage Bookmarks, Global History, bookmarks sidebar tab, etc.) so it wouldn't hurt to check those out when verifying this bug.
I'll check all these trees with my new fixes.
Status: NEW → ASSIGNED
Blocks: 51833
I have played around with all the trees with my patch and don't see any of these glitches. Will check in soon.
*** Bug 55360 has been marked as a duplicate of this bug. ***
Attached patch Fix — — Splinter Review
a=hyatt. This bug is ready for the PDT. PDT, this patch fixes a whole slew of tree problems, all related to the fact that the dirtying of tree elements was not happening correctly since the row construction occurred during reflow. Now that we've moved that out, these sorts of painting and reflow glitches will be fixed, since everything will be dirtied properly when changes occur. This bug is vital. Please nominate for rtm++. It's medium risk with extremely high payback.
Whiteboard: [rtm+ need info] → [rtm+]
Attached patch Patch with hyatt's corrections. — — Splinter Review
r=bryner, although I would suggest fixing the char[100] buffer/sprintf problem we talked about and cleaning up the comments (noticed a lot of typos) if you have time.
PDT would like to evaluate the medium risk by landing on the trunk first. Let us know how it goes.
Has landed on trunk.
This is an amazing improvement. If one bug fix makes it on the the branch, this is it.
Ok fix on trunk. PDT please take a look I would like to get this to the branch as soon as possible.
Whiteboard: [rtm+] → [rtm+] PDT please review
I didn't see this bug in mail on any smoketested builds today branch or trunk.
Linux (2000-10-09-09 MN6) Win32 (2000-10-09-09 MN6) Mac (2000-10-09-10 MN6) I do not see any problem on today's branch builds
Keywords: vtrunk
i see this, there is a considerable difference between trunk and branch builds. This fix really needs to make in into RTM for lower speed machines.
huh? I still see this too. the fix hasn't been checked in to the branch yet.
For the record, another place I see this in browser scrolling thru the ftp sites list for builds on sweetlou ie: ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/ Scrolling halfway then trying to scroll partway up, the topmost items will usually disappear.
And, for the record, what you describe is in the _branch_ builds, but not the _trunk_ builds, right? I have been bashing on trees in mail, bookmarks, sidebar, ftp, etc. since Friday night with optimized _trunk_ builds, and I have not observed a single place where the tree "loses rows", paints incorrectly, "gets confused" or crashes. This patch is extremely solid.
Seth, after I tried many times, I can see the problem on Win32 branch build now. However, both Esther and I can no see the bug on Linux and Mac branch builds. Since we see it on win32, I download the win32 trunk build (2000-10-09-09 M18) build, I do not see the problem.
it looks like everyone is in agreement: it is fixed on the trunk, but not the branch.
Possible dup of bug 51227?
Yes, I saw the problem on the branch builds .. WIN32 2000-10-09-09MN6
PDT marking [rtm++] due to great trunk testing (thanks all!)
Whiteboard: [rtm+] PDT please review → [rtm++] PDT please review
*** Bug 51833 has been marked as a duplicate of this bug. ***
No longer blocks: 51833
Checked into branch.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Linux (2000-10-12-11 MN6) Win32 (2000-10-12-13 MN6) Mac (2000-10-12-10 MN6) I do not see the problem on Win32 any more. I tried it on MAC and Linux, do not see the problem. Verify it.
*** Bug 56166 has been marked as a duplicate of this bug. ***
*** Bug 56166 has been marked as a duplicate of this bug. ***
Keywords: vtrunk
Verified Fixed on Mozilla trunk builds linux 101908 RedHat 6.2 win32 101904 NT 4 mac 101904 Mac OS9 Removing vtrunk keyword
I still see some problems with trees (tried it with bookmarks and mail folders). Open some folder so you can scrolls the window. Scroll it down. Minimise the window and restore it : no more tree (sometimes all leafs, sometimes some)
Oops. Forgot to tell I'm using build 2000102220 trunk on winNt4
Maybe we should reopen this bug : I sometimes see problems with ther refresh of the bookmarks sidebar. Open a folder with loads of bookmark, scroll down so the opened folder is the first shown. Close it. Some lines disappear until I scroll one more time or resize the sidebar. Done with 2000120720 trunk NT4 Sp6a Avi of the problem : http://www.multimania.com/sconest/Mozilla/refresh.avi
If you still see this problem I would suggest logging a new bug using the Browser component. Unfortunately I cannot reproduce the problem using build 2000-12-12-09 using NT4.
Reopeninig. Actually, this got never completely fixed in Mac builds. I have been seeing some sort of refresh failure in folder pane on expanding. However this week's builds show a pretty ugly refresh bug in thread and folder panes during and after scrolling. MTrunk 2000122010 MacOS9.
ccing myself.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
In addition to bug 59032, bug 58435, bug 58432, bug 58990, filed for other specific modes where the tree fails, we have bug 43326, which is for the particular case of the tree not painting properly when the threadPane is maximized (depending on the initial position of the scrollbar). Marking this bug as FIXED again.
RIP
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: