Closed Bug 29808 Opened 24 years ago Closed 24 years ago

Mailnews/Aim windows sometimes doesn't refresh display

Categories

(Core :: XUL, defect, P1)

x86
Linux
defect

Tracking

()

VERIFIED DUPLICATE of bug 35921

People

(Reporter: rzach, Assigned: blizzard)

References

Details

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

Attachments

(2 files)

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: beta1beta2
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: 24 years ago
Resolution: --- → DUPLICATE
Please ignore the spam.  Changing address.
Assignee: blizzard → blizzard
Status: RESOLVED → NEW
busted from my reassign
Status: NEW → RESOLVED
Closed: 24 years ago24 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: