Open Bug 534994 Opened 15 years ago Updated 2 years ago

Strange behaviour when selecting "Subscribe" with no folder selected. (IMAP, blank subscription list is shown, because login for LSUB fails due to "IMAP: password prompt failed or user canceled it")

Categories

(MailNews Core :: Networking: IMAP, defect)

x86
All
defect

Tracking

(Not tracked)

People

(Reporter: bwinton, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

STR: Create a folder named "deleteme". Delete the folder. (This leaves you with nothing selected in the folder panel.) Select "File » Subscribe…". I also see "JavaScript error: chrome://messenger/content/subscribe.js, line 276: serverMenu is undefined" on the console. And it happens on trunk as well.
LSUB command for subscribe operation is usually issued via existent cached connection kept for opened folder. If there is no cached connection after restart of Tb, Tb tries to connect to IMAP server, but it fails, then nothing is shown at subscription panel. Log is for next: (1) Restart Tb. No folder is selected by Tb, so no cached connection. (2) Subscribe => Nothing is shown in subscription list panel. Login to server failes. (3) Refresh at Subscribe => Nothing is shown in subscription list panel. Login to server failes. (4) Open an IMAP folder named Inbox2. Login to server, 5 select "Inbox2", connection is kept. (5) Subscribe => subscription list is shown normally. 9 lsub "" "*", 10 list "" "%", is issued at connection for Inbox2. Log was obtained with next trunk nightly build, but same phenomenon is observed with Tb 3.1.7. > Mozilla/5.0 (Windows NT 5.1; rv:2.0b12pre) Gecko/20110205 Thunderbird/3.3a3pre I frequently saw this phenomenon for long time during testing of Tb, because; (a) I disable automatic new mail check, (b) I usually select account instead of folder before terination of Tb in order to avoid automatic folder access by Tb just after restart of Tb. Confirming.
Component: Mail Window Front End → Networking: IMAP
OS: Mac OS X → All
Product: Thunderbird → MailNews Core
QA Contact: front-end → networking.imap
Version: 3.0 → Trunk
Summary: Strange behaviour when selecting "Subscribe" with no folder selected. → Strange behaviour when selecting "Subscribe" with no folder selected. (IMAP, blank subscription list is shown when no cached connection exists)
Following is log for login failure for subscribe during no cached connection. > 00000014 44.79429626 [1176] 3468[4467e80]: IMAP: password prompt failed or user canceled it > 00000015 44.79434204 [1176] 3468[4467e80]: login failed entirely
Summary: Strange behaviour when selecting "Subscribe" with no folder selected. (IMAP, blank subscription list is shown when no cached connection exists) → Strange behaviour when selecting "Subscribe" with no folder selected. (IMAP, blank subscription list is shown, because login for LSUB is required if no cached connection is available but it fails)
Bug 645856 may be related to this bug.
See Also: → 645856
does this still happen on the trunk? My suspicion is that the subscribe UI's docShell wasn't allowing password prompts and I thought we fixed that.
This bug is still observed with next latest trunk nightly build. > Mozilla/5.0 (Windows NT 5.1; rv:9.0a1) Gecko/20110911 Thunderbird/9.0a1 IMAP log for (1) Subscribe at context meny of IMAP account when no connection is established, (2) Refresh at subscription list panel(nothing is shown). > [596] 4424[59a87c0]: IMAP auth: server caps 0x80C0625, pref 0x1006, failed 0x0, avail caps 0x4 > [596] 4424[59a87c0]: (GSSAPI = 0x1000000, CRAM = 0x20000, NTLM = 0x100000, MSN = 0x200000, PLAIN = 0x1000, LOGIN = 0x2, old-style IMAP login = 0x4)auth external IMAP login = 0x20000000 > [596] 4424[59a87c0]: trying auth method 0x4 > [596] 4424[59a87c0]: IMAP: password prompt failed or user canceled it > [596] 4424[59a87c0]: login failed entirely > [596] 4424[59a87c0]: 8979000:imap.gmail.com:NA:ProcessCurrentURL: aborting queued urls > [596] 4424[59a87c0]: 8979000:imap.gmail.com:NA:TellThreadToDie: close socket connection > [596] 4424[59a87c0]: ImapThreadMainLoop leaving [this=8979000] > [596] 1720[10116c0]: ImapThreadMainLoop entering [this=1eaa800] > [596] 0[100f140]: 1eaa800:imap.gmail.com:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN > [596] 1720[10116c0]: 1eaa800:imap.gmail.com:NA:ProcessCurrentURL: entering > [596] 1720[10116c0]: 1eaa800:imap.gmail.com:NA:ProcessCurrentURL:imap://yatter%2Eone%40gmail%2Ecom@imap.gmail.com:993/discoverallandsubscribedboxes: = currentUrl > [596] 1720[10116c0]: ReadNextLine [stream=101bb08 nb=0 needmore=1] > [596] 1720[10116c0]: 1eaa800:imap.gmail.com:NA:CreateNewLineFromSocket: clearing IMAP_CONNECTION_IS_OPEN - rv = 804b0014 > [596] 1720[10116c0]: 1eaa800:imap.gmail.com:NA:TellThreadToDie: close socket connection > [596] 1720[10116c0]: 1eaa800:imap.gmail.com:NA:CreateNewLineFromSocket: (null) > [596] 1720[10116c0]: 1eaa800:imap.gmail.com:NA:ProcessCurrentURL: aborting queued urls > [596] 1720[10116c0]: ImapThreadMainLoop leaving [this=1eaa800] > [596] 4692[10116c0]: ImapThreadMainLoop entering [this=1eaa800] > [596] 0[100f140]: 1eaa800:imap.gmail.com:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN > [596] 4692[10116c0]: 1eaa800:imap.gmail.com:NA:ProcessCurrentURL: entering > [596] 4692[10116c0]: 1eaa800:imap.gmail.com:NA:ProcessCurrentURL:imap://yatter%2Eone%40gmail%2Ecom@imap.gmail.com:993/ensureExists%3E%5EAA%5EJunk: = currentUrl > [596] 4692[10116c0]: ReadNextLine [stream=3ccb5c8 nb=68 needmore=0] > [596] 4692[10116c0]: 1eaa800:imap.gmail.com:NA:CreateNewLineFromSocket: * OK Gimap ready for requests from 222.9.106.185 m6if1315833pbd.99 > [596] 4692[10116c0]: 1eaa800:imap.gmail.com:NA:SendData: 1 capability > [596] 4692[10116c0]: ReadNextLine [stream=3ccb5c8 nb=109 needmore=0] > [596] 4692[10116c0]: 1eaa800:imap.gmail.com:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH > [596] 4692[10116c0]: ReadNextLine [stream=3ccb5c8 nb=45 needmore=0] > [596] 4692[10116c0]: 1eaa800:imap.gmail.com:NA:CreateNewLineFromSocket: 1 OK Thats all she wrote! m6if1315833pbd.99 > [596] 4692[10116c0]: try to log in > [596] 4692[10116c0]: IMAP auth: server caps 0x80C0625, pref 0x1006, failed 0x0, avail caps 0x4 > [596] 4692[10116c0]: (GSSAPI = 0x1000000, CRAM = 0x20000, NTLM = 0x100000, MSN = 0x200000, PLAIN = 0x1000, LOGIN = 0x2, old-style IMAP login = 0x4)auth external IMAP login = 0x20000000 > [596] 4692[10116c0]: trying auth method 0x4 > [596] 4692[10116c0]: IMAP: password prompt failed or user canceled it > [596] 4692[10116c0]: login failed entirely > [596] 4692[10116c0]: 1eaa800:imap.gmail.com:NA:ProcessCurrentURL: aborting queued urls > [596] 4692[10116c0]: 1eaa800:imap.gmail.com:NA:TellThreadToDie: close socket connection > [596] 4692[10116c0]: ImapThreadMainLoop leaving [this=1eaa800]
Simpler way to see phenomenon of this bug. Start Tb in offline mode(thunderbird.exe -offline p "..."), click IMAP account(to avoid unwanted server connection), go Work Online, Subscribe. If Offline mode after successful login, phenomenon is slightly different. - Start Tb in offline mode(thunderbird.exe -offline p "...") - go Work Online mode, click IMAP folder to open => login is done - go Work Offline mode - Subscribe => progress bar is shown forever, until cancel
Summary: Strange behaviour when selecting "Subscribe" with no folder selected. (IMAP, blank subscription list is shown, because login for LSUB is required if no cached connection is available but it fails) → Strange behaviour when selecting "Subscribe" with no folder selected. (IMAP, blank subscription list is shown, because login for LSUB fails due to "IMAP: password prompt failed or user canceled it")
As of 17.0.2, the issue with "Manage Folder Subscriptions" (bug 645856) is not fixed. Behavior is identical to TB 5.0.
See Also: → 709504
This still exists today, because it fails at https://dxr.mozilla.org/comm-central/source/mailnews/imap/src/nsImapProtocol.cpp#8448 . GetMsgWindow() seems to return no window thus fetching the password (even if stored in password manager) isn't attempted. It is weird because the window (msgWindow variable) isn't used anywhere after trying to retrieve it... Maybe it would be fetched again by some of the called functions thus we abort early before it fails somewhere deeper in the PM.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: