now that jefft has integrated with single sign on, I can't read my imap mail or download pop messages. it works if I choose not to remember my password (in the password dialog there is a checkbox now). this is on a freshly migrated 4.x account.

Happens also with newly created accounts on linux

Pulling the tree on windows and debbuging on linux .... It was working for me yesterday. I thought I have done a pretty thorough test yesterday. Sorry...

Looks like we never get back from the password dialog. I don't think the mail/news code were the culprit. USER32! 77e72ada() nsWebShellWindow::ShowModalInternal(nsWebShellWindow * const 0x039e35a0) line 1467 + 20 bytes nsWebShellWindow::ShowModal(nsWebShellWindow * const 0x039e35d0) line 1433 + 12 bytes nsWebShellWindow::ShowModally(nsWebShellWindow * const 0x039e35d8, int 0) line 1509 + 16 bytes GlobalWindowImpl::OpenInternal(JSContext * 0x0297e7b0, long * 0x00d4bd68, unsigned int 4, int 1, nsIDOMWindow * * 0x0012eb74) line 2612 GlobalWindowImpl::OpenDialog(GlobalWindowImpl * const 0x0297d128, JSContext * 0x0297e7b0, long * 0x00d4bd68, unsigned int 4, nsIDOMWindow * * 0x0012eb74) line 2453 nsCommonDialogs::DoDialog(nsCommonDialogs * const 0x03838600, nsIDOMWindow * 0x0297d128, nsIDialogParamBlock * 0x039e0090, const char * 0x020e56f4) line 430 + 29 bytes nsCommonDialogs::UniversalDialog(nsCommonDialogs * const 0x03838600, nsIDOMWindow * 0x0297d128, const unsigned short * 0x00000000, const unsigned short * 0x039e0f70, const unsigned short * 0x039e22f0, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * 0x00000000, ...) lin nsWebShellWindow::UniversalDialog(nsWebShellWindow * const 0x02988084, const unsigned short * 0x00000000, const unsigned short * 0x039e0f70, const unsigned short * 0x039e22f0, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * ...) line nsNetSupportDialog::UniversalDialog(nsNetSupportDialog * const 0x03838770, const unsigned short * 0x00000000, const unsigned short * 0x039e0f70, const unsigned short * 0x039e22f0, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * ...) l wallet_GetDoubleString(nsAutoString & {...}, unsigned short * 0x039e22f0, unsigned short * 0x039e39d0, unsigned short * 0x039e2120, int & 0) line 927 + 88 bytes Wallet_SetKey(int 0) line 1438 + 40 bytes si_SetKey() line 276 + 7 bytes si_SaveSignonDataLocked(int 1) line 1802 + 5 bytes si_PutData(char * 0x03838d10, nsVoidArray * 0x039e5730, int 1) line 1528 + 7 bytes si_RememberSignonDataFromBrowser(char * 0x03838d10, nsAutoString {...}, nsAutoString {...}) line 2199 + 15 bytes SINGSIGN_PromptPassword(const unsigned short * 0x03838e10, unsigned short * * 0x0012fc9c, const char * 0x03839ef0, nsIPrompt * 0x0298f3f4, int * 0x0012fca0) line 2371 + 52 bytes nsWalletlibService::PromptPasswordURL(nsWalletlibService * const 0x02975470, const unsigned short * 0x03838e10, unsigned short * * 0x0012fc9c, const char * 0x03839ef0, nsIPrompt * 0x0298f3f4, int * 0x0012fca0) line 125 + 25 bytes nsWebShellWindow::PromptPassword(nsWebShellWindow * const 0x0298f3f8, const char * 0x03839ef0, const unsigned short * 0x038380d0, const unsigned short * 0x03838e10, unsigned short * * 0x0012fc9c, int * 0x0012fca0) line 2860 + 48 bytes nsMsgIncomingServer::GetPasswordWithUI(nsMsgIncomingServer * const 0x0331bc00, const unsigned short * 0x03838e10, const unsigned short * 0x038380d0, nsIMsgWindow * 0x03326260, char * * 0x0398fe40) line 583 nsImapIncomingServer::PromptForPassword(nsImapIncomingServer * const 0x0331bc3c, char * * 0x0398fe40, nsIMsgWindow * 0x03326260) line 1339 + 32 bytes XPTC_InvokeByIndex(nsISupports * 0x0331bc3c, unsigned int 17, unsigned int 2, nsXPTCVariant * 0x03832c50) line 139 EventHandler(PLEvent * 0x038329a0) line 473 + 41 bytes PL_HandleEvent(PLEvent * 0x038329a0) line 526 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00c80410) line 487 + 9 bytes _md_EventReceiverProc(HWND__ * 0x00050270, unsigned int 49329, unsigned int 0, long 13108240) line 975 + 9 bytes USER32! 77e71820() 00c80410()

I don't think single-signon is the culprit either. The loop is in ShowModalInternal in nsWebShellWindow.cpp. Here's the code that we are looping on: while (NS_SUCCEEDED(rv) && mContinueModalLoop) { void *data; PRBool isRealEvent, processEvent; rv = subshell->GetNativeEvent(isRealEvent, data); if (NS_SUCCEEDED(rv)) { window->ModalEventFilter(isRealEvent, data, &processEvent); if (processEvent) subshell->DispatchNativeEvent(isRealEvent, data); } } Another datapoint. For an existing profile, even one without an existing single-signon/wallet database, this problem does not occur.

See also: bug 21596 (Loss of network connectivity after using dialog) Bug 25789 is probably a duplicate of this one.

*** Bug 25727 has been marked as a duplicate of this bug. ***

Something's very fishy here. At first I wasn't able to see this bug -- it was working fine for me. Then I deleted my profile and my mozregistry.dat file and started over. Then I was able to get this hang. But after playing with this for a while, I was again unable to reproduce it. So I started over once again -- removed my entire registry and my mozregistry.dat file. Re-entered browser. This time the mail password dialog came up just fine. No hang! This is exactly the same thing that I did previously when I was able to reproduce the hang. So now I'm very confused. :-(

It seems pretty easy for me to reproduce, I just delete signon.tbl, *.key & *.psw files and it happened.

Yes, now I'm again in a mode where it is very easy to reproduce. Not exactly sure what happened to me before.

When I get the problem, it is always on the second dialog. The first dialog asks for the mail password and that one works. The second one is for the database key and that is the one that hangs. I can force the database key password to be asked for before entering mail, and in that case the hang is on the request for the mail password. In fact, I discovered that a second dialog anywhere will no longer work (either hangs or does nothing). See bug report 25833. So this bug has nothing to do with mailnews, nothing to do with single-signon, and everything to do with dialogs. I'm marking this bug as a dup of 25833 rather than the opposite; the way focus can be kept on the fundamental issue of dialogs without having mailnews or single-signon cloud the issue. *** This bug has been marked as a duplicate of 25833 ***

duplicate bug is marked fixed. However, Esther, we should verify this case.

Using builds 2000021409m14 on linux and win98 and 20000211m14 on mac this is fixed. Verified