Build ID: 2000010713 Platform: All To reproduce: - Launch mozilla - Select Tasks | Mail - Click the Get Msg button Result: The app never actually checks mail. You can't stop it, can't close the window, can't quit the app; you have to force-quit the app instead. This is using a POP server; it works okay on Linux using an earlier build.
This also seems to be a problem on Windows 98. Using Win 98, I can't ever actually log into the POP server, but I can close the window and/or quit the app. I can't Stop the logon process either. Using the 2000010708 Linux build, mail worked okay for me with the same POP server.
Apparently people who have this problem are those with remember password turned off. The mac is apparently hanging when we try to bring up the password dialog on imap and pop. This bug isn't pop specific. cpratt, can you confirm that you aren't using remember password on the accounts that are failing for you? Thanks.
cpratt, yell at us if we are incorretly changing the summary of this bug. Paul's been playing around with this bug some more and it appears that modal dialogs on the mac are broken in general. This includes the password dialog, bringing up the new card in the address book window, etc.
dougt thinks this might be him.
The failure to read mail on windows that you reported in this bug was due to Bug #23378 where dns look ups were failing. To keep this bug focused on Mac modal dialogs, I'mgoing to remove win32 from the summary line.
Dougt is taking over this bug. Re-assigning to him. Thanks Doug. An easy browser dialog to see the hang is open web location.
my mac is dead, however, try this fix. I am not sure it works. RCS file: /cvsroot/mozilla/widget/src/mac/nsMacMessagePump.cpp,v retrieving revision 1.88 diff -r1.88 nsMacMessagePump.cpp 271c271 < if (aRealEvent == PR_TRUE) --- > if (aRealEvent == PR_TRUE && anEvent->what != nullEvent)
The change to: if (aRealEvent == PR_TRUE && anEvent->what != nullEvent) did not help. Still hang. :-(
The current event queue needs to be fetched each time events are processed, rather than reusing a cached queue. All better now.
Seems to be broken in the 2000011008 Win32 build as well. I'm leaving this as RESOLVED FIXED until I can be 100% sure of that though.
I don't see the problem with a (debug) build from this morning.
I don't see this problem with today's build, either. I'm going to reopen the mozilla tree.
Linux (2000-08-25-08 M18) Win32 (2000-08-25-08 M18) Mac (2000-08-25-04 M18) This bug should be closed. An old old bug that has been fixed