Open Bug 881114 Opened 11 years ago Updated 2 years ago

When defaultaccount = Local Folders(non POP3/non IMAP account) is set by Tb after default account deletion, if Local Folders(non POP3/non IMAP account) doesn't have Inbox, new mail check by login_at_startup is not invoked

Categories

(MailNews Core :: Backend, defect)

defect

Tracking

(Not tracked)

People

(Reporter: World, Unassigned, NeedInfo)

References

(Depends on 1 open bug)

Details

This is spin-off of bug 854098 comment #35. If following conditions occur at same time, (a) defaultaccount = Local Folders, (b) Local Folders doesn't have folder of "SpecialUse flag=Inbox", new mail check by login_at_startup is not invoked. [Steps to reproduce] (1) Set "Local Folders" as default account. mail.accountmanager.defaultaccount = accountN where accountN is Local Folders account; mail.accountmanager.localfoldersserver = serverX => mail.account.accountN.server = serverX This is emulation of "defaultaccount=Local Folders after default account deletion" such as bug 854098 comment #31. (2) Remove Inbox folder of "Local Folders" if Inbox exists. Delete file of "Inbox" and "Inbox.msf" under ...\Mail\Local Folders directory. (3) Enable automatic new mail check and download of POP3 account. mail.server.serverP.type = pop3 mail.server.serverP.login_at_startup = true (set by account wizard) mail.server.serverP.check_new_mail = true (set by account wizard) mail.server.serverP.download_on_biff = true (set by account wizard) (4) Restart Tb => Mail is NOT downloaded automatically. (5) Create Inbox under Local Folders, Restart Tb. => Mail is downloaded automatically. (6) Rename files or Local Folders : Inbox=>XYZ, Inbox.msf=>XYZ, Restart Tb (folder flag="Inbox" is written in .msf, so XYZ has Inbox flag) => Mail is downloaded automatically. (7) Delete XYZ, XYZ.msf, Restart Tb => Again, mail is NOT downloadeda automatically. (8) Change default account to hidden "smart mailboxes"(type=none, for Unified Folders), mail.accountmanager.defaultaccount = accountZ Restart Tb => Mail is downloaded automatically. i.e. If following conditions occur at same time, (a) defaultaccount = Local Folders, (b) Local Folders doesn't have folder of "SpecialUse flag=Inbox", new mail check by login_at_startup is not invoked.
"Existence check of Inbox of Local Folders" may be for "Global Inbox use, with Global Inbox owner is Local Folders", after change of "creation of special folder other than Trash, Outbox is not executed upon Local Folder account creation" which was made by user's requests.
Summary: When defaultaccount = Local Folders is set by Tb after defaul account deletion, if Local Folders doesn't have Inbox, new mail check by login_at_startup is not invoked → When defaultaccount = Local Folders is set by Tb after default account deletion, if Local Folders doesn't have Inbox, new mail check by login_at_startup is not invoked
Note that no Inbox folder exists in Local Folders if only IMAP accounts were set up before. An Inbox is only created there if you have at least one POP3 account which uses the Global Inbox.
This appears to apply for POP3 accounts only. I'm unable to reproduce this with a profile that has the Local Folders account only (no Inbox) and an IMAP account. Switching defaultaccount to localaccount presents Local Folders on top of the Account Settings, but login prompt and mail download still works for the IMAP account even after that change.
Depends on: 880464, 880602
Summary: When defaultaccount = Local Folders is set by Tb after default account deletion, if Local Folders doesn't have Inbox, new mail check by login_at_startup is not invoked → When defaultaccount = Local Folders is set by Tb after default account deletion, if Local Folders doesn't have Inbox, new mail check by login_at_startup of POP3 account is not invoked
(In reply to rsx11m from comment #3) > This appears to apply for POP3 accounts only. FYI. - mail.server.serverP.download_on_biff=true is POP3 only attribute. - "Global Inbox" is POP3 only feature, and "Local Folders" can be set in mail.server.serverX.deferred_to_account of an POP3 account. - Similar action to "fetch header only in POP3" is always executed in IMAP(currently, by uid x:y fetch body.peek[headers(Subject From ...)]) - In IMAP, "download_on_biff=true in POP3 without fetch header only" corresponds to "Auto-sync=Enabled && Offline-Use=On".
When "Local Folders", because mail.server.serverX.login_at_startup=true is set by Account Manager upon "Local Folders" account creation, nsIMsgIncomingServer.loginAtStartUp == true is set. It's needed for "Global Inbox" support. So, perhaps by following code. > http://mxr.mozilla.org/comm-central/source/mail/base/content/msgMail3PaneWindow.js#734 > 734 function loadStartMsgHdr(aStartMsgHdr) > 782 // Get the user pref to see if the login at startup is enabled for default account > 783 isLoginAtStartUpEnabled = defaultServer.loginAtStartUp; > 784 > 785 // Get Inbox only if login at startup is enabled. > 786 if (isLoginAtStartUpEnabled) > 787 { > 788 //now find Inbox > 789 var outNumFolders = new Object(); > 790 const kInboxFlag = Components.interfaces.nsMsgFolderFlags.Inbox; > 791 var inboxFolder = rootMsgFolder.getFolderWithFlags(kInboxFlag); > 792 if (!inboxFolder) return; <== Skip new mail check at here > 793 > 794 startFolder = inboxFolder; > 795 } When mail.server.serverX.login_at_startup=false is set for "Local Folders", problem is not reproduced. So, I think above guess is correct. Trick in defaultaccount="smart mailboxes" is perhaps loginAtStartUp=false. If "smart mailboxes" for Unified Folder(type=none too), mail.server.serverZ.login_at_startup=true is not generated by Tb. And, nsIMsgIncomingServer.loginAtStartUp=false was actually set by Tb(checked by mail.server.serverZ.hidden = false). So, above "skip when defaultServer.loginAtStartUp==true && default account doesn't have Inbox" doesn't occur, and goes ahead.
Internally, actual conditions are; (A) Default account's mail.server.serverX.login_at_startup=true (b) Default account doesn't have folder of "SpecialUse flag=Inbox" By the way, this is another "needless problem due to forcing Global Inbox feature use to any user always" for me. - Forcing X-Account-Key: header use in identity selection to any user => unwanted preset From: in Reply, unwanted archive setting use - This bug, forced login_at_startup=true of Local Folders, despite that user never uses Local Folders as deferred-to account.
FYI. However, who actually exposed or generated this bug is; change of "permit delete of default account" In older Tb, "Remove Account" was rejected by graying out the menu, if default account. So, user had to change default account to appropiate one before remove currently defaulted account. Therefore, this bug couldn't occur, unless user manually, intentionally alters prefs.js setting(usually, called "prefs.js corruption").
Severity: normal → minor
FYI. Following is applicable to News&Blog account(rss) too. - Account's mail.server.serverX.login_at_startup=true - Account doesn't have folder of "SpecialUse flag=Inbox" So, this bug occurs also when RSS account is set as default after default account deletion.
line 783 merely obtains defaultServer.loginAtStartUp value, doesn't it? I think "skip of new mail check" is done by line 792, as I wrote in comment #5.
Yeah sorry, I missed that you already pointed to this same code in comment 5. So the question is why do we base this logic on the default server? Why is it special? Why are not all POP3 servers checked individually if they need to download at startup?
Reading bug 66460, the intention there was to check for mail for the default server (only?), thus maybe that's still around for historical reasons? FWIW, SeaMonkey's implementation of loadStartFolder() looks a bit different: mail/ > 792 if (!inboxFolder) return; > 794 startFolder = inboxFolder; suite/ > 885 if (inboxFolder) > 886 initialUri = inboxFolder.URI; while otherwise being equally based on defaultserver.
(In reply to rsx11m from comment #12) > Reading bug 66460, the intention there was to check for mail for the default > server (only?), thus maybe that's still around for historical reasons? My understanding is that the basic mail check doesn't download any messages. For IMAP that doesn't matter because selecting the folder automatically downloads new headers for that folder, but when your default server is a POP server then it would be confusing if your new mail didn't download. In other words, even if the "Automatically download new messages" preference is unset it still downloads new messages in your default POP account.
"Automatically download new messages" is not "Check for new messages at startup". Or did you just mean that one?
(In reply to aceman from comment #14) > "Automatically download new messages" is not "Check for new messages at > startup". Or did you just mean that one? Sorry if I was unclear. If you have "Check for new messages as startup" set to true for your default POP account, then it automatically downloads new messages, even if the account isn't set to automatically download new messages.
(In reply to neil@parkwaycc.co.uk from comment #15) > If you have "Check for new messages as startup" set to true for your default POP account, > then it automatically downloads new messages, even if the account isn't set to automatically download new messages. It's perhaps implementation by bug 66460, and is already changed. As I wrote in bug 854098 comment #29, new mail notification(biff) of POP3 in Tb 17 is invoked only after download of mail using RETR/TOP which is invoked by download_on_biff=true(biff_after_download may be proper?). This is because biff is done after message filter/junk filter. According to such change, "always download regardless of download_on_biff if defaulted POP3" is already killed, and Tb 17 actually issues STAT/LIST/UIDL only(no RETR/TOP) when login_at_startup==true and download_on_biff==false. RETR/TOP is issued only when (login_at_startup==true || check_new_mail==true) && download_on_biff==true, even if defauled POP3 account. I guess this change is reason why I don't see report such as "periodical new mail check doesn't stop after disabling check new message every NN minutes" these days. (In reply to rsx11m from comment #12) > mail/ > > 792 if (!inboxFolder) return; > > 794 startFolder = inboxFolder; > suite/ > > 885 if (inboxFolder) > > 886 initialUri = inboxFolder.URI; I think "startFolder = inboxFolder" in Tb is perhaps for "show Inbox of default account as selected at folder pane" stated in that bug. I think, before "delete of default account" is accepted and RSS account is supportd and Unified Folder is introduced, "defaultaccount=Local Folders" could occur only when "pop3 account only" and "Local Folders is deferred_to_account of all POP3 accounts", even if it occurred. And, when Local Folders is used as defered_to_account, Inbox of Local Folders is automatically created by Tb. I guess this is reason why "if (!inboxFolder) return" is simply called in Tb.
As for "defaultaccount=Local Folders" case, following change is solution. As done on "creation of Inbox of Local Folders", - set login_at_startup=true of Local Folders only when Local Folders is used as deferred_to_account of a POP3 account. - when POP3 account stops to use Local Folders as deferred_to_account, reset to login_at_startup=false. No need to wait for fixing of bug 880464 and bug 880602 in "Local Folders" case.
(In reply to neil@parkwaycc.co.uk from comment #15) > (In reply to aceman from comment #14) > > "Automatically download new messages" is not "Check for new messages at > > startup". Or did you just mean that one? > > Sorry if I was unclear. If you have "Check for new messages as startup" set > to true for your default POP account, then it automatically downloads new > messages, even if the account isn't set to automatically download new > messages. At least for me this is not correct. I have enabled "Check for new messages at startup" and have to download the messages separately. Perhaps the download happens automatically when the check for new mails is also enabled for SeaMonkey browser windows (mail.biff.on_new_window = true).
Well, maybe the behaviour was changed since the default account login at startup code was written, but I'm pretty sure it used to be the case. (I still have an old profile somewhere that is set up with a POP account but the version installed is equally old and tends to crash, which is why I don't use it any more.)
Summary: When defaultaccount = Local Folders is set by Tb after default account deletion, if Local Folders doesn't have Inbox, new mail check by login_at_startup of POP3 account is not invoked → When defaultaccount = Local Folders is set by Tb after default account deletion, if Local Folders doesn't have Inbox, new mail check by login_at_startup is not invoked
Summary: When defaultaccount = Local Folders is set by Tb after default account deletion, if Local Folders doesn't have Inbox, new mail check by login_at_startup is not invoked → When defaultaccount = Local Folders(non POP3/non IMAP account) is set by Tb after default account deletion, if Local Folders(non POP3/non IMAP account) doesn't have Inbox, new mail check by login_at_startup is not invoked
Blocks: 1033226
No longer blocks: 1033226
(In reply to WADA:World Anti-bad-Duping Agency from comment #0) > If following conditions occur at same time, > (a) defaultaccount = Local Folders, > (b) Local Folders doesn't have folder of "SpecialUse flag=Inbox", > new mail check by login_at_startup is not invoked. After bug 342632, Local Folders can't be selected as the default account. (In reply to WADA:World Anti-bad-Duping Agency from comment #7) > FYI. > However, who actually exposed or generated this bug is; > change of "permit delete of default account" > In older Tb, "Remove Account" was rejected by graying out the menu, if > default account. So, user had to change default account to appropiate one > before remove currently defaulted account. Therefore, this bug couldn't > occur, unless user manually, intentionally alters prefs.js setting(usually, > called "prefs.js corruption"). There should be no reason to prevent user from deleting accounts, even if it is the last one. A new default account will be selected automatically so why force the user to do it manually. Also, after bug 342632, if the last mail account is deleted, there will be no default account (null) even if Local Folders exists. After bug 880602 a new default account should be picked up as soon as you create a new mail (pop/imap) account so it should not stay stuck on null or Local folders. Could you please re-check if there is still any problem left?
Flags: needinfo?(m-wada)
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.