25710 - can't read imap mail (or download pop inbox) if I choose "remember password"

Status: VERIFIED DUPLICATE of bug 25833

(MailNews Core :: Backend, defect, P3)

Description

[(not reading, please use [e-mail] instead)]

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.

Comment 1

[Andreas Otte]

Happens also with newly created accounts on linux

Comment 2

[jefft]

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...

Comment 3

[jefft]

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()

Comment 4

[Stephen P. Morse]

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.

Comment 5

[Richard Zach]

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

Comment 6

[Richard Zach]

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

Comment 7

[Stephen P. Morse]

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. :-(

Comment 8

[jefft]

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

Comment 9

[Stephen P. Morse]

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

Comment 10

[Stephen P. Morse]

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 ***

Comment 11

[lchiang]

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

Comment 12

[esther]

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