Closed Bug 124578 Opened 24 years ago Closed 24 years ago

Mailnews is dead (shows only busy cursor)

Categories

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

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.9

People

(Reporter: Matti, Assigned: fabian)

References

Details

(Keywords: regression, smoketest)

Attachments

(3 files)

JS console output during mailnews startup
14.02 KB, image/png
Details
Busy cursor on IMAP folder
33.05 KB, image/png
Details
Proposed fix.
2.17 KB, patch
Bienvenu
: superreview+
Details | Diff | Splinter Review
win2k build 20020209.. (10 min old CVS build, clobbered) 1. Open MailNews 2. You see a busy cursor and Mozilla doesn't show any mails All buttons are working (Get Msgs, Compose)
Keywords: smoketest
same on Linux, build ~1 hour ago os->All
OS: Windows 2000 → All
Are there any errors displayed in the Js console? Can you provide a screenshot for us build-less? Is this happening for IMAP only or other account types as well?
håkan: I noticed it in News, not Imap. Imap doesn't work either, though. Screenshot: Well, there's nothing special to be seen, really. The message list doesn't contain anything, and the area where the message would be seen still contains the standard message ("Welcome to Mozilla Mail & News") Do you still want a screenshot? JS Console contains this message, but I don't know if it's related: Warning: reference to undefined property window.setCursor Source File: chrome://messenger/content/msgMail3PaneWindow.js Line: 1125
I have been experiencing the same thing on a Windows XP machine. I first noticed it with the nightly builds from about 2-3 days ago, and it is not present in the one I rolled back to (2002020208). It's a pretty hideous bug, leaves my entire browser app locked up, machine at 100% CPU, memory growing stedily and fast (about 500K per second). I have had to kill the process and lose the email I was writing in each case. It basically renders the mozilla nightly build unusable for me, and it doesn't trigger the talkbacks which might give you guys some insights. If I can capture any other information, please let me know. The bug recurs very reliably on my laptop. It has hit me 4 or 5 times now. Rick Ross
Rick, I think your problem is a different bug - does it occur when deleting a selection of text? This bug does not cause any noticable CPU usage for me.
Confirming for Mozilla 0.9.8+ Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.8+) Gecko/20020208 The "busy" cursor occurs when the INBOX or other IMAP folders are active, but NOT on local folders or on nntp folders. See screenshots for JS console output - looks like an IMAP related thing ....
This is not IMAP specific. I see the behavior with POP as well.
Keywords: regression
I've tried to backout varga (me) and danm so far. Mailnews is still busted. Trying others...
My first blocker ever, yay. Reassigning to myself, sorry for all the trouble. Somehow I broke nsGlobalChromeWindow::SetCursor(), even though it's exactly the same function that was in nsGlobalWindow before. Investigating.
Assignee: sspitzer → hidday
Priority: -- → P1
Target Milestone: --- → mozilla0.9.9
OK. Everyone who's seeing the setCursor messages (or getAttention ones, for that matter) please remove your component.reg (which you should be doing by instinct if you build optimized). That will fix those problems. It does _not_ fix this bug.
bz, I did remove component.reg, but I still get the setCursor messages.
just FYI, here are backout commands to fix this bug: cvs update -j1.46 -j1.45 mozilla/xpfe/global/resources/content/commonDialog.js cvs update -j1.35 -j1.34 mozilla/extensions/venkman/resources/content/venkman-debugger.js cvs update -j1.44 -j1.43 mozilla/extensions/irc/xul/content/static.js cvs update -j1.419 -j1.418 mozilla/docshell/base/nsDocShell.cpp cvs update -j1.163 -j1.162 mozilla/dom/src/base/nsGlobalWindow.h cvs update -j1.482 -j1.481 mozilla/dom/src/base/nsGlobalWindow.cpp cvs update -j1.93 -j1.92 mozilla/dom/src/base/nsDOMClassInfo.cpp cvs update -j1.67 -j1.66 mozilla/dom/src/build/nsDOMFactory.cpp cvs update -j1.17 -j1.16 mozilla/dom/public/idl/base/nsIDOMWindowInternal.idl cvs update -j1.2 -j1.1 mozilla/dom/public/idl/base/nsIDOMChromeWindow.idl cvs update -j3.13 -j3.12 mozilla/dom/public/nsIDOMScriptObjectFactory.h cvs update -j1.19 -j1.18 mozilla/dom/public/nsIDOMClassInfo.h cvs update -j1.3 -j1.2 mozilla/dom/public/idl/base/MANIFEST_IDL cvs update -j1.3 -j1.2 mozilla/dom/macbuild/dom_baseIDL.xml cvs update -j1.14 -j1.13 mozilla/dom/public/idl/base/makefile.win cvs update -j1.10 -j1.9 mozilla/dom/public/idl/base/Makefile.in
>> Rick, I think your problem is a different bug - does >> it occur when deleting a selection of text? >> This bug does not cause any noticable CPU usage for me. Christian, I have not noticed this occurring on text deletion, but rather it occurs while I am entering text in a new message. At least 3 times it has happened after I hit "enter" to start a new paragraph. It has also happened while typing in the middle of a sentence. I can reinstall the latest nightly and try to capture whatever specific details you guys want/need. It is a killer bug, very bad and occurs reliably. Rick
bz and I came up with a fix... currently testing it to make sure nothing else is broken
Status: NEW → ASSIGNED
Attached patch Proposed fix. — — Splinter Review
Darn, this one was hard to track down! With the invaluable help from bz we came up with this patch. Several people have tested it and reported it fixes all the issues. I also added a defensive check in directory.js because it has the same code and might run into the same problems some day. This patch has r=bz. Need sr= from jst or from a mailnews guy, thanks in advance. And sorry again for the trouble.
fabian, that file is tab-indented. Your patch is space-indented... please tab-indent it like the rest of the file (yes, ugly, I know).
I was talking about the msgMail3PaneWindow.js changes when I mentioned indentation, btw.
Comment on attachment 68740 [details] [diff] [review] Proposed fix. sr=bienvenu. we are trying to replace all tabs with spaces, so I would say spaces are ok.
Attachment #68740 - Flags: superreview+
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
*** Bug 124660 has been marked as a duplicate of this bug. ***
Maybe it's not related to this but after I recompiled the fix checked in here, I now crash every time I try to send out an HTML msg with an atatchment. I was not crashing like this with yesterday's build.
did the build of yesterday which worked fine already have the symptoms reported in this bug? (i.e. was the patch for bug 30529 already checked in?) if yes: i'm stomped because I don't know how a fix in msgMail3PaneWindow.js could affect the compose window if no: then it's probably not my fault do you get any assertions/js error? Can anyone else reproduce that crash?
> did the build of yesterday which worked fine already have the symptoms > reported in this bug? (i.e. was the patch for bug 30529 already checked in?) I compile from the source and don't apply individual patches. So, the answer is: if the patch was not checked in the source, it is not in my private buld. I know that the patch for this fix was used in my build.
well it depends when you built yesterday.. the patch for bug 30529 was checked into the tree (and caused this blocker) so you probably had it... I'd like the people in this bug to test your crash, if possible. I'm currently not able to test it.
Sending an HTML Message with an attachment works fine for me.
Is this fix already in the nigthlies? Mail in Build 2002020908 is completely unusable for me.
Momoi, if you can pull the tip, rebuild, trash component.reg, create a new profile, and still reproduce it - please file a new bug... with a stack, and CC me. :-) Thanks. This bug is fixed.
Status: RESOLVED → VERIFIED
simon, it's not in the build you mentioned - it was checked in yesterday at 14:17 PST. Your build was made at 8 PST (as you can see from the last two digits of your build id). All builds created after 14:17 yesterday will contain the fix. afaict no windows build was created since then, only Linux, FreeBSD, HP-UX and SGI IRIX.
*** Bug 124755 has been marked as a duplicate of this bug. ***
*** Bug 124768 has been marked as a duplicate of this bug. ***
*** Bug 124816 has been marked as a duplicate of this bug. ***
*** Bug 124851 has been marked as a duplicate of this bug. ***
Were any of the pre-checkin tests run before the fix was checked in (which caused this bug)? I'm wondering if that may have prevented this bug from showing up in the builds where a component completely stopped working.
it's entirely my fault I didn't test mailnews before checking this patch in... the debug build I was working on didn't build mailnews and I didn't run the pre-checkin tests. I'll make sure it doesn't happen again. yes running the pre-checkin would have prevented this
In comment #23, I said that I had a crashing problem when sending a mail msg. I think I know why now. It has nothing to do with this bug. It has to do with a general PSM crash bug I am experiencing. It so happens that when I send out mail, Mozilla tries to atatch an S/MIME signature and it leads to a crash due to Bug 124568.
*** Bug 124954 has been marked as a duplicate of this bug. ***
*** Bug 125529 has been marked as a duplicate of this bug. ***
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: