Closed Bug 82778 Opened 24 years ago Closed 24 years ago

unable to quit after reading mail then closing all windows

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
PowerPC
Mac System 9.x
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED MOVED

People

(Reporter: bugzilla, Assigned: naving)

References

Details

(Keywords: hang, platform-parity)

found this while verifying bug 78807, using 2001.05.24.08 comm bits. if i read mail, then close all windows i cannot quit the app --need to jump into Macsbug and hit 'es'. 1. open mail, read a msg [eg, click on a msg in the thread pane]. 2. close mail window, and all other windows you might have open, via either File > Close or cmd+W. 3. quit the app by selecting File > Quit. expected: app should quit. result: app doesn't quit. note: if i have mail open, but *don't* view any msgs, i don't encounter this problem. pink mentioned that if he waits about 5-10sec, the app does manage to quit eventually. however, i haven't experienced this --the menubar/app is still running after waiting about 3min.
Keywords: nsbeta1, pp
I have encountered this bug, but would report it slightly differently. Using the Mac build 2001052508 here are my steps to reproduce this bug: 1. Close all open windows. 2. I am unable to open a new Navigator window, but can open anyother window (Mail, Adress, Composer). 3. I am unable to quit Mozilla or acess a new Navigator window. 4. A force-quit is my only option. If this is the same bug, which I believe it is, I would change the severity to critical. Even if this is not the same bug, it definitely should be fixed before the 9.1 upcomming Mozilla release! I am sorry if my bug report ends up being for a different bug, but I am trying not to duplicate bug reports as the 9.1 release approaches.
(note: this bug should *not* be confused with bug #74499 which has to do with command-keys not working at all. Sairuh's test case calls for using the File menu.)
interesting: i couldn't repro this using either a news-only account or a pop-mail account, with 2001.05.29.08 mozilla bits. i'll doublecheck when i'm in the office tomorrow with the latest commercial and moz bits...
Severity: normal → major
to clarify: i had originally seen this using an test imap account [3qatest01].
i'm using imap. i still see this on the 5/30/01 mac bits, though it does eventually quit. if i have both mail and navigator open when i quit, the following happens: - mail window closes immediately, nav window stays - app sits for 5-10 seconds, machine is responsive to clicks and events - nav window closes and immediately app quits breaking into macsbug during this time doesn't show anything. it's as if we're waiting for an async task to complete.
pink / sarah, in your imap server prefs do you have "empty trash on exit" or "clean up inbox on exit" checked? cc'ing bienvenu / naving
i appear to have 'cleanup (expunge) inbox on exit' checked.
for the imap acct both of those prefs ["empty trash on exit" and "cleanup inbox on exit] are off [ie, not checked]. so, i checked both the commercial and mozilla 2001.05.31.08 bits: this is still a problem with the commercial build, but *not* a problem with the mozilla build. hm.
Keywords: hang
pink/se: try using Interachy to look for network I/O during this delay. Also, in debug builds, maybe turning on imap NSPR logging would help.
methinks this is commercial-only [anyone else experience this in mozilla?] --also see the hang with news-only and pop mail accts.
reassigning to Navin since this looks like it's an empty trash on exit problem. Mike, could you try turning that off and see if your problem goes away?
Assignee: sspitzer → naving
bienvenu, i don't have either of those settings turned on --do you still think it's an empty trash on exit issue? just curious.
If you don't have any of these settings on, the exit should be very smooth. I will investigate.
no, it can't be that, then. I would be curious if pink's problem goes away, though. There could be two problems.
We think that AIM might be the culprit here. I can repro the problem if I open the IM window without ever using mail. Maybe sairuh had the buddy list open in her mail sidebar?
Makes sense since that's only possible in commercial build - adding Syd to cc list.
Hrm, scrap that. I can repro the bug using the mail window, no IM. I think this will turn out to be a XUL/focus/command issue, though pink's timeout observation doesn't fit with that theory.
i think aim [nim] is the issue here. when i install commercial *without* nim, i don't see this problem. however, when nim is there --whether or not i created a screenname-- this hang occurs. suggest moving this to bugscape.
OK, I agree with sairuh now. I had the buddy list (closed) in my sidebar in mail (although this happens even when I remove it). If I remove the AIM dll from my commercial build, then the problem does not happen. So let's go over to bugscape.
This worksforme as long as I don't have aim buddy list in the sidebar. buildid 053108.
I will move this, but I think it's a dupe of some of the other IM bugs we have with the setup/buddy list causing crashes elsewhere.
Bug moved to http://bugscape.netscape.com/. If the move succeeded, lchiang@netscape.com will recieve a mail containing the number of the new bug in the other database. If all went well, please mark this bug verified, and paste in a link to the new bug. Otherwise, reopen this bug.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → MOVED
somehow the move didn't succeed, so i created a bugscape report: http://bugscape.mcom.com/show_bug.cgi?id=5711.
verified moved
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.