0.9.2 public release, NT 4.0 I found 2 cases where I can crash Zilla when closing the mail-window. NT shows an error-dialog, but I haven't seen a Talkback window. Note: I haven't been using turbo mode, becuase it crashed too often - maybe this is related. 1) - go to preferences, and make sure that *only* Navigator is selected to open at startup - close Zilla - start Zilla as 'mozilla -mail', which will open the mail-window, despite the preference. I do this very often with 'IMAP Notify', a biff-like mail-notifier (since Zilla *still* doesn't have a systray icon for that !), or from a shortcut on my desktop. - everything runs fine - close the mail window ==> crash 2) - go to preferences, and make sure that both Navigator and Mail are selected to open at startup - close Zilla and open it again (the normail way) - both mailwindow and navigatorwindow will open - close the navigator first - close the mail-window ==> crash Example 2 shows that the reason of the crash is that you can't close a mailwindow, when there's no navigator window around. In example 1, if I open a navigator window first, before closing mail, I don't have a crash. But I open a navigator window, close it immediately, and close the mail-window (as the last one), I still have a crash. So the mail-window can never be the last one. Possibly related to bug 60953 or 63897
This works for me on win2k build 20010704.. Reporter: Can you try it with a new profile ? run "mozilla -profilemanager" and create a secound profile for a test. "run mozilla -p Profilename -mail" .... Which version of mozilla you are using ? The installer or the .zip build ?
I'm running 0.9.2, the large installer (8.5 MB). When I create a new profile, I don't get the error. But I suspect that's because the mail-account isn't setup completely (I'm in an intranet here, and I can't setup a dummy mail-account). When I create a new account which duplicates my existing account (but with leave mail on server), it crashes too. When I read bug 60953 or bug 63897, I can see that the mailer will try to contact the remote server when the window is closed. I suspect that this doesn't work when there's no navigator window around. The work around is alwasy very simple : make sure that there's a navigator window open when you close the mail window. The bug is very easy to reproduce for me, if I forget to close the windows in the correct order. PS : I'm using a LDAP email-account on a Lotus Notes mailserver (sigh ...).
Some more info : - when I run Mozilla in turbo mode, I don't see the bug. That's probably because not everything is unloaded from memory, even when the mail-window is the only real window. - I could only crash when I was sure that the mailserver (LDAP !!!) was contacted by Zilla. This can happen when I click on a message that has to be downloaded first (and that's not in the cache somewhere), or when I contact the mailserver manually. The problem was that LDAP sometimes uses the cache to show you the document, when the LDAP-server doesn't respond immediately (and there's no progress window or another notification that the server has really been contacted - but that's another bug). When I was testing Zilla by starting and closing very quickly, sometimes the server was contacted, sometimes it was not (so I saw a mail from the cache). Only when there was actual connection, I had the crash. I can't confirm this directly (haven't used a packet analyzer yet), but I knwo 1 thing : if I'm *really* sure that the LDAP-server has been contacted, there will be a crash. PS : our LDAP-server is rather unreliable. I'm not surprised that the connnection sometimes fails, sometimes not. The problem in this case, is that there's no feedback at all for success or failure. And clearing the LDAP cache is also not obvious (if you don't know that there is one, you'll never guess that you have to clear the memory and disk caches !). I'll look later if this has been reported before.
Reporter: Can you try to download the talkback.zip build ? (http://ftp.mozilla.org/pub/mozilla/releases/mozilla0.9.2/mozilla-win32-0.9.2-ta lkback.zip) (You can extract it in a different directory) After that crash talkback should catch this crash. After talkback submitted the crash, run "Install_Dir\components\talkback.exe" and post the Talkback ID# in this bug. With this TB ID# we can get a stack trace of that crash and we can see exactly where we crash. (I can't reproduce this because I have no LDAP. Maybe the QA can help) Thanks firstname.lastname@example.org ! Matthias Versen
Assignee: sspitzer → srilatha
Component: Mail Window Front End → LDAP Mail/News Integration
QA Contact: esther → yulian
ccing dmose, leif and olga. The talkback report will be very helpful.
Eh ... I can't confirm it with talkback.zip. Then I noticed that this 2nd installation (I kept my previous one) has messed up my original installation (left toolbar icon was missing, something went wrong with my proxyserver, etc ...), so I decided to uninstall both versions, and install the original again (installer.exe). I haven't seen the bug anymore (still running with my original profile). I'll wait a few days to see if comes back. My IMAP server is acting strange today too, so the bug might be related to that (the fact that it appeared yesterday, or the fact that it doesn't appear today. Sigh. PS : why doesn't the 'talkback enabled Installer.exe' have a talkback.exe, but the 'talkback enabled Zipfile' does ?
> - I could only crash when I was sure that the mailserver (LDAP !!!) was > contacted by Zilla. This can happen when I click on a message that has to be > downloaded first (and that's not in the cache somewhere), or when I contact > the mailserver manually. The problem was that LDAP sometimes uses the cache to > show you the document, when the LDAP-server doesn't respond immediately (and > there's no progress window or another notification that the server has really > been contacted - but that's another bug). A mailserver itself is a program that does mailbox-related stuff via POP, or in your case, IMAP. Though it's possible for the machine that's running the mailserver to also be running (or referring to) an LDAP server, the mail itself is not downloaded via the LDAP protocol. At this point, LDAP is only used for compose-window autocompletion. Just viewing a message will never touch the LDAP server. So this bug can't possibly be LDAP related at all. Moving to the IMAP component, and reassigning.
Assignee: srilatha → mscott
Component: LDAP Mail/News Integration → Networking - IMAP
Sorry about the confusion between IMAP and LDAP - I have be programming LDAP-interfaces too many these days. It's an IMAP mailserver ofcourse, although I'm doing autocomplete on the LDAP-server (which happens to be the same database). I haven't been able to reproduce this problem with 0.9.2 (public release) or 0.9.2 (2001071508). This bug can be closed as a WORKSFORME.
Reassign to Karan as QA contact
QA Contact: yulian → huang
Marking as worksforme based on the reporter's comments & my verification for the latest branch build.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
Verified worksforme(No crash)on WinNT 07-15-08-0.9.2 for closing Mail-window for the following two scenarios: 1) Preferences|Appearance|Start up Navigator 2) Preferences|Appearance|Start up Navigator & Netscape Mail
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.