Closed Bug 29808 Opened 25 years ago Closed 25 years ago

Mailnews/Aim windows sometimes doesn't refresh display

Categories

(Core :: XUL, defect, P1)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 35921

People

(Reporter: rzach, Assigned: blizzard)

References

Details

(Keywords: platform-parity, Whiteboard: [nsbeta2+])

Attachments

(2 files)

maybe a clue...crash after refresh problem incident 6462811
7.65 KB, text/plain
Details
Bug appears for me after opening this (mbox) folder
11.05 KB, text/plain
Details
For about a week or so, I've had this problem where sometimes Mailnews would go into a state where selecting a message or switching folders doesn't cause the window to be repainted. In that situation, it looks like UI events have no effect. E.g., I'd click on a folder in the folder pane, but the thread pane would not refresh. If I Alt-Tab away and back, the new folder displays in the thread pane. I don't know how to reproduce it, but it seems like it tends to happen more often after longer use, and with biff on. morse remarked on a simlar problem in bug 28100 where the save password checkmark wouldn't repaint after being clicked, and suggested it would be a threading problem. I thought I'd file a bug on it, and add comments as I discover more. Anyone else seeing this? Linux build 2000.03.01.08
I haven't seen this, but if bringing the window to the back and then to the front again fixes it, I'm guessing it's a painting problem. Not sure whether to start with layout or XPFE, but I'll guess trudelle and cc rickg.
Assignee: phil → trudelle
reassigning to pavlov as p3 for m15. Might be higher priority if we knew the steps to reproduce and the frequency.
Assignee: trudelle → pavlov
Target Milestone: M15
It happened again, so I'll describe what I'm seeing. I was reading a message, and then clicked delete. Mail window has been open maybe 2 hours without problems. Then: 1. Clicking on a message displays it in the message pane, but the thread pane doesn't update the selection. 2. No mouseover or click effects in the toolbar. Clicking delete deletes the message, refreshes the message pane, but doesn't remove the header from the thread pane. 3. Selecting a folder updates the folder selection, thread pane, window title, and message pane, but only if the folder has not yet been opened during the session. If it has, then there is no visible effect, except for changing the window title. 4. Collapsing or expanding a folder has no visual effect. 5. Collapsing the message pane by clicking on the grabber works once, but expanding and then collapsing it again doesn't. All this of course does works in the sense that forcing a repaint (alt-tab away and back) shows it happened. When I then close the mail window and open it again, the parts that were still working before (message pane and window title) were also broken: the message pane just shows the start page, the window title the default folder name, even after I force a repaint.
After I quit and restarted Moz, I still saw this: I select a newsgroup folder with no new messages to download I get in that situation described (maybe I did before and didn't notice). That kept happening through 3 restarts, now it's fixed again.
I've seen this, too. I've logged a bunch of different bugs on pavlov for painting problems. adding myself to the cc list, to see what happens. instead of alt-tab, you can just cover the window with another window (like an xterm) and force a repaint.
Bug 30319 might be related.
adding myself to the cc on this one.
This now happens to me every time I open n.p.m.general. Makes MailNews pretty much unusable. Now, when it happens, it also prevents HTML form controls in the browser window from repainting with selected values, and the scrollbar does not refresh (although the window scrolls) in the browser. (Linux build 2000.03.05.09). Seth, kdowling, do you see that too on new builds? What do you want to do with bug 30319?
Severity: normal → blocker
Keywords: beta1, dogfood
Putting on the PDT- radar for dogfood. If you can get a reproducible test on ALL platforms, let us know. Can Relnote for beta1.
Keywords: relnote
Whiteboard: [PDT-]
*** Bug 30319 has been marked as a duplicate of this bug. ***
I didn't see it at all with 2000030509. I've seen it once with 2000030613. But that was after I crashed in n.p.m.ui on purpose to get a back trace. Next time I tried to go back to n.p.m.ui, it happened. I exited, deleted the .msf for that group and reloaded it. Hasn't happened since.
It just happened again, when going from my Sent folder to Trash. This was without having touched any newsgroups. I had just deleted the one message in the Sent folder. Clicked on Trash to see if it was there, and it did it. I just tried exactly the same sequence again and it didn't.
linux build 2000030709.... This is so elusive. I can't *make* it happen, but it happens all the time now.
Lisa asked me to try to reproduce and here's what I found, maybe not the same thing. I have, however, been able to reproduce this several times. I was not able to get any refresh problems to occur on my linux machine (linux rh6.0, HP vectra 400Mhz). On my NT 4.0 machine (Compaq Deskpro, 166Mhz) I was able to get consistent refresh problems, primarily in the message pane, when reading through newsgroups and changing amongst them. The problem progressed to where eventually the thread pane would not refresh with proper folder/group thread list. When this situation occurred Alt+Tab or other methods to refresh did not help, I had to exit and relaunch. Here's what I'm doing/seeing on NT 4.0 using 2000-03-07-09m15 commercial build: 1. Launching a profile with one IMAP mail account and several news accounts. 2. Biff is off. 3. I login to my IMAP account, read an Inbox message, switch to another mail folder. All is ok. Thread pane and message pane refreshes with proper content for every selection I make. 4. I open one of the mozilla newsgroups, have been particularly looking at n.p.m.seamonkey. I let all new headers download, I am in a date sort. 5. I select a news message, then another, reading through several. All is ok. I scroll through the list and make a selection here and there while scrolling is still catching up (scrolling can be slow on my NT machine). All message selections/content eventually catches up. All is ok. 6. I select another newsgroup, netscape.test. I do the same thing in this group that I did in n.p.m.seamonkey. Select, read, scroll. All is ok. 7. I switch back to n.p.m.seamonkey and begin to notice within a few selections that the message pane content is not updating to any new selection, past selection content is there and same content stays no matter what message I select. Thread pane selection is updating, but still not message/header panes. 8. I select my mail inbox. Thread pane updates appropriately, but message pane is still stuck in past news message selection. 9. I try selecting a message in inbox. Thread pane shows selection, message pane is still stuck. I Alt+Tab and come back, still in same state. 10. I select n.p.m.seamonkey again and find nothing refreshes at all. Folder pane won't show selection, thread pane won't refresh, message pane still stuck. 11. At this point I exit and return and all is ok again.
QA Contact: lchiang → laurel
I attached a stack trace (incident 6462811). I got this crash after leaving my machine in the no-refresh state (as I described in detail above) and came back after a few minutes. When I tried to make another selection in the thread pane I crashed.
On linux, I've never crashed while in this state. And, it only occurs (when it occurs) upon selecting a folder (newsgroup or mail) in the left pane. Once it starts, it continues. All the while, there is a process/thread chewing up cpu cycles as fast as it can.
This one isn't going away. I don't know why it's [PDT-]. It makes mail/news completely unusable on linux. The best I can do at reproducing this consistently is to read newsgroups. I click on a newsgroup and let it grab new headers. I use the [Next] button to read through all new messages. I then click on the next newsgroup. It goes into this strange state. The happens *almost* all the time. What can I do to help find this thing?
running strace on the spinning process, these are the three system that its spinnint around... gettimeofday({953198885, 99628}, NULL) = 0 ioctl(8, FIONREAD, [0]) = 0 poll([{fd=8, events=POLLIN}, {fd=6, events=POLLIN, revents=POLLIN}, {fd=13, events=POLLIN}], 3, 0) = 1 Don't know it this helps... fd=6 and 13 are pipes, fd=8 is a unix stream socket. I'm doing a cvs checkout right now so I can build a debug build and see if I can't locate this thing...
The bug is PDT- because we don't have steps to reproduce which indicate that the bug is easy to encounter. At this point, bugs getting PDT+ have to be so bad that if they were discovered after we shipped b1, we'd pull the beta off the FTP site to fix it. So far, this bug doesn't meet that standard. Of course, this bug is important, as they all are, but there's more time to fix them. We need to be done with beta1.
I narrowed this down to some interaction between NSPR and pthreads. I don't know enough about threaded processes to do much more. I guess my 128Mb w/64M swap isn't enough to debug this anyway. I can't get much further without running out of memory and crashing out of X.
I also saw this bug often, but was unable to reproduce. I'll keep an eye open. But I noticed the following: - I never saw it in the msg pane - I did see it in the preferences (which I invoked from Mailnews, I don't use the browser extensively) - *IIRC* (I'm not sure), the bug also actually appeared in the preferences, i.e. the preferences worked first, but after some clicks (and not closing them), the bug appeared. Additional Comments: The bug also often appeared after Mailnews was running only some minutes (or shorter). I'm running - RH6.0 with lots of packages from 6.1 (e.g. glibc 2.1.2) and gtk/glib 1.2.3-1 - Celeron 300A, 128MB RAM with ~70 MB swap - UW-IMAP (news doesn't work for me, so it's not a news-only bug) - a non-Mozilla IMAP biff, which checks every 30s
> - I never saw it in the msg pane I.e. even when the bug was appeared, the msg pane still redrawed. I was able to click blindly on msgs in the thread pane, got no feedback from the latter, but the new msg was displayed in the msg pane.
re the message pane.... same here. Maybe something in common about the systems? I'm running redhat 6.1 (glibc-2.1.2-11) with all redhat updates applied. A kernel from rawhide... 2.2.14-1.1.0. gtk+/glib 1.2.7-1rh61 from weaver's rpms. Intel PII 400Mhz, 128MB Ram 64MB swap. UW IMAP 4.5.
I see redraw problems in the browser, too. However, they manifest slightly differently, e.g. sometimes, only a part of the window redraws, even if I move another window on top of it. I often see problems with forms, e.g. the "commit" button doesn't show a pressed state.
Keywords: pp
Moving to Browser|Widgets.
Component: Front End → XP Toolkit/Widgets
Product: MailNews → Browser
ben, i think this is just a buttons don't press kind of bug... can you take a look? Are the things that this bug originally describes still happening? I don't see them.
Assignee: pavlov → ben
Yes, this is still happening. It's not a 'buttons don't push' problem. When the browser doesn't refresh properly here, it's after the problem has occured in mail-news. It happens when switching from one folder or newsgroup to another. Once it happens, it continues, with that one process sucking up all CPU cycles, until you exit mozilla completely.
I'm seeing this consistently in mailnews in the last few m15/trunk commercial builds. It's affecting new account wizard and account settings dialog tremendously (like described in older bug #28100 and bug #27717), as well as selecting among folders. Particularly horrible switching among folders in a second mail window. Just thought I'd update comments as I hadn't seen regularly in past weeks.
Just a guess: Maybe, it's the amount of widget changes? Mailnews should do a lot of that, and the problems I saw in the browser were with bugzilla, IIRC. (Did you ever see Mozilla update the components after you selected a product in the query page? Lots of widget changes.)
I'm moving this to M16. I really don't think it _has_ to be fixed for M15. Feel free to argue with me ...
Priority: P3 → P1
Target Milestone: M15 → M16
The very same bug appears in the prefs of AIM of the commercial Netscape 6 beta 1 as well, so it's really not Mailnews-specific. I didn't see it in recent builds of Mozilla so often (at all?).
I continue to see this in *every* build. When it happens, it always happens when clicking a mail/news folder. From that point on, it appears everywhere. I've never seen it *start* anywhere else but by clicking on a mail/news folder. I usally can't read more than three or four newsgroups before I have to exit mozilla completely because it has become unusable.
Nominate for beta2
Keywords: beta2
I put that mbox file on my IMAP server and was able to open/read and switch among folders without the problem occuring due to that file.
Everytime I click on this folder, an eventually existing scrollbar in the thread pane disappears, but the content doesn't update. If I click one of the first msgs, this msg is updated (and highlighted), but the other ones remain as they are (i.e. I still see the content of old folder). Dunno, if it will work on your system (I'm using UW-IMAP on a netwrok server). However, this is not the typical behaviour. Usually, after I clicked on a msgs, the whole folder displayed. Also, this bug often also propagated to the preferences (e.g. I clicked on a checkbox and it was selected, but not shown as selected), but doesn't do after clicking on this folder. Well, maybe it helps. kdowling, as I said, I saw it in the Netscape 6 PR 1 build in AIM's proferences, and there was no Mailnews open at all.
Keywords: beta2
Keywords: beta1 → beta2
Whiteboard: [PDT-]
Very strange. I didn't see any of those problems with this mbox folder. I'm also using UW IMAP (v4.5), but on localhost. This machine is networked, but I use fetchmail to grab mail from all my pop3 servers out on the net into my mail spool. Then I read mail with IMAP on localhost. I am currently using mozilla build 2000040708.
mailnews is *totally* unusable for me because of this bug. I'm not sure it belongs with ben, though. the smoketesters passed today's build despite my inability to use mail, though, so not holding the smoketests because of this. There's no way we're shipping a release if the refresh problems are this bad when we get there, so i'm not sure if the relnote keyword is appropriate, either. Removing.
Keywords: relnote
I'm not sure about how bug #35594 fit into this problem...just thought I'd reference it here. These general bugs are rampant and confusing in seamonkey.
Marking beta2+ based on feedback
Whiteboard: [beta2+]
This affects AIM windows in the standalone, sidebar Buddy list and sometimes in Add Buddy dialogs. CC amusil,syd,prass,scalkins
Summary: Mailnews window sometimes doesn't refresh display → Mailnews/Aim windows sometimes doesn't refresh display
So, sometimes it takes a while to get into this state, but once i'm in it, i'm stuck: symptoms: operations in the thread pane do not force redrawing of either the thread pane, or the message headers in the message window. The message *body* updates, but not the header info until i cover the window with another window, or move the grippy. potentially related, is that highlighting of text in a text form (such as the one i'm writing this report in), by doubleclicking or dragging the mousepointer, doesn't display until i force a redraw (by covering with another window). This happens with list-select elements as well. Seth suspects invalidateRegion code not triggering redraws. This is definitely *not* ben's bug.
Ok, I can't reproduce this on a regular basis either but it sure is there. Last night ( Apr 12th ) we had this problem really, really bad. It happened any time that windows were destroyed. Some box changes exposed it. Syd was commenting that this had been a problem for a long time and I think he's right. The next time it happens to me I'm going to try to track it down in the debugger.
If you're in this state, and you cause a modal dialog to appear, for example by typing a bogus URL into the URL bar, everything is fine again.
*** Bug 35198 has been marked as a duplicate of this bug. ***
reassigning to blizzard, as he is conscious of the problem, and frequently using a build with debugging symbols (not to mention that he like, knows how to use the debugger, and stuff),
Assignee: ben → blizzard
Accepting...
Status: NEW → ASSIGNED
Well, i was just tarring up the binaries over here on my FreeBSD box and noticed this: Are the makefiles pulling all of the package sources?? Just thought i'd mention this . . . pete /usr/src/M15/mozilla/dist/bin $ tar cfh - . | ( cd /web/main/RELEASE/package; tar xf - ) tar: Could not create file chrome/messenger/content/default/mail3PaneWindowVertLayout.xul : No such file or directory tar: Could not create file chrome/messenger/content/default/mailWindowOverlay.xul : No such file or directory tar: Could not create file chrome/messenger/content/default/mailWindowOverlay.js : No such file or directory tar: Could not create file chrome/messenger/content/default/mailWindow.js : No such file or directory tar: Could not create file chrome/messenger/content/default/messageWindow.xul : No such file or directory tar: Could not create file chrome/messenger/content/default/messageWindow.js : No such file or directory tar: Could not create file chrome/messenger/content/default/mailCommands.js : No such file or directory
Huh? What does that have to do with this bug?
So, the actual reason why things aren't being updated is event queue starvation. When the layout engine says to invalidate that region, the paint request is added to a list of invalidations that will be run the next time the mainloop gets back up to the idle loop. We do this for performance reasons. The problem is that the timer is never fired because glib never gets back up to the mainloop because of the event queue starvation. Something, somewhere is abusing the hell out of the event queue. Tracking it down now...
*** This bug has been marked as a duplicate of 35921 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Please ignore the spam. Changing address.
Assignee: blizzard → blizzard
Status: RESOLVED → NEW
busted from my reassign
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Keywords: nsbeta2
Updating [beta2+] in Status Summary to [nsbeta2+]
Keywords: beta2
Whiteboard: [beta2+] → [nsbeta2+]
I don't see the problem in mailnews anymore, so I'm going to go ahead and mark this verified as a duplicate. I'm on the cc list of the master bug, so when it's marked resolved I'll revisit the mailnews issues, too.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: