Closed Bug 94671 Opened 24 years ago Closed 15 years ago

For POP3 servers, make 'Automatically download new messages' work with 'Check for new messages at startup' too

Categories

(SeaMonkey :: MailNews: Message Display, enhancement)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
Windows NT
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: rflazaro, Unassigned)

References

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.3) Gecko/20010801 BuildID: 2001080110 when i start up the mail reader it does not get the new mail even if i selected the Check for new mail at startup option it used to work before this build... Reproducible: Always Steps to Reproduce: 1. go to Edit->Mail/News Accounts Settings 2. select a pop account 3. select server settings 4. select the Check for new mail at startup option 5. create a new message and send it to yourself 6. exit the mail reader 7. startup the mail reader Actual Results: it does not check for new mail at startup Expected Results: it should check for new mail at startup if the Check for new mail at startup option is selected
QA Contact: esther → sheelar
*** This bug has been marked as a duplicate of 71105 ***
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
in the email i received its status was changed from uncomfirmed to resolved and it was indicated to be a duplicate i am using build 2001081208 on WinNT and it still does not work, so it is not yet resolved
i read bug 71105, it has something to do with biff and is not related to this bug this bug has something to do with the mail reader when i say mail reader i mean the Mozilla mail/news window frontend not a an external program like biff
reopening the bug
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Reporter, If you have check new mail at startup checked it will prompt you with the password dlg and upon giving the correct password if you have new messages on the server we just indicate it with the biff icon that you have new mssgs to download. We actually do not download the messages with that preference. The preference that actually downloads your message after you log in is "Automatically download any new messages" and have this checked with the biff settings and you should be able to download the message. Marking this bug as invalid because we do not download mssgs with this preference we only check for new mail and just indicate it with the biff arrow only if the account is authenticated.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → INVALID
i am not using biff or any external program to check for new messages so this is not a duplicate of bug 71105 it used to be that if Check mail at startup was selected upon startup of the mail reader it would download the new email, so it seems that is not the way it is supposed to be can i request that feature?
Wait - I see your problem (dup tunnel vision, my bad). This is occurring on the startup of messenger. As sheelar pointed out, Mozilla won't download the messages - it will put a green arrow (depending on theme) on top of the mail icon in the status bar and on the mailbox icon. If you're not seeing this visual indicator when you have new mail, or you have "download new messages" turned on, change the bug back to a bug. Otherwise I'm changing this to an RFE and updating the summary.
Severity: normal → enhancement
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Summary: check for new mail at startup not working → [RFE] Automatically download new messages by default when checking mail at startup
Changing status to confirmed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
i'm using build 2001081303 on WinNT but I don't see a green arrow or any indicator that there is/are new messages even when 'Check for new mail at startup' is selected I think this is a bug and I should file another report for my RFE to have an option to 'Automatically download new mail at startup'
This bug is actually caused by the pref "Automatically download new messages" being taken out of its context. This pref is a sub-pref under the "Check new messages every X minutes" pref, and should only affect that pref, instead it affects the Check mail at startup pref. I GUESS I could see why you would want it to check mail and at startup and not actually download it, but seems kinda silly. Would suggest having Automatically download new messages" as a sub-pref of this also, or simply have it do that by default.
*** Bug 95638 has been marked as a duplicate of this bug. ***
i think that there should be a sub-pref of 'Check for new mail at startup' which would 'Automatically download new mail at startup' or you can make it a pref of its own
reassign to bhuvan since he worked on the check mail at start up behavior for 6.1 Reporter, I see that if you have the perf "automatically download any new messages" checked with the biff settings. Then the message is downladed with the pref check mail at start up. I am not sure if we need another pref for this. cc jglick if to see if another pref is needed or change the check mail at start up behavior to also download the message instead of just checking for new mail on the server
Assignee: sspitzer → racham
I am using build 2001100803 on Win2K Yes that is what is happening. [x] Check for new mail at startup [ ] Check for new messages every [ ] minutes [ ] Automatically download new messages - only a green down arrow is shown indicating new mail------------------------------------------------------ [x] Check for new mail at startup [x] Check for new messages every [ ] minutes [ ] Automatically download new messages - only a green down arrow is shown indicating new mail ------------------------------------------------------- [x] Check for new mail at startup [x] Check for new messages every [ ] minutes [x] Automatically download new messages - messages are downloaded and green down arrow is shown indicating new mail Is this current behavior 'correct' ?
yes that is correct behavior
[x] Check for new mail at startup [ ] Check for new messages every [ ] minutes [x] Automatically download new messages In theory, this should download new messages that are available on startup (and never check after that). Does it?
Navin's post: yes that is correct behavior My reply: If this is the correct behavior I believe it would be better if 'Automatically download new messages' is not a sub-pref of 'Check for new messages every [ ] minutes' but rather a pref on its own... Or if that is the desired behavior by design then it is best that the documentation say it explicitly. Current documentation (Setting POP Server Information) --- * Select "Check for new mail at startup" if you want Mail to automatically check this account for new messages whenever you start Mail. For POP accounts, Mail doesn't download the new messages until you click Get Msg on the Mail window toolbar. * Select the setting "Check for new messages every ___" and then specify the number of minutes between mail checks. If you do not select this setting, you can check for new messages at any time by clicking Get Msg in the Mail window. * Select "Automatically download any new messages" if you want Mail to retrieve messages immediately each time it checks the server. --- Maybe you could add a note saying 'If you want to get new messages at startup select Check for new messages every N minutes and Automatically download new messages' or something along that line. A potential 'problem' is for people who want to immediately get new messages at startup but do not want to continually set the application to Check for new messages every N minutes after startup. I am not pushing for this or anything, the current behavior is fine with me. I think the documentation should say it behaves like this so people don't get 'confused'. =)
Skewer's post: [x] Check for new mail at startup [ ] Check for new messages every [ ] minutes [x] Automatically download new messages In theory, this should download new messages that are available on startup (and never check after that). Does it? My reply: Automatically download new messages is a sub-pref of Check for new messages every N minutes and therefore is disabled until Check for new messages is checked/selected =)
This is something that we may want to explain in detail in our documentation as Roderick suggested. I agree it is a bit problem for those who do not want to have the app check mail every once in a while, just because they wanted to get new messages at startup. Jennifer, did any of user study experiences suggested the above mentioned as a major problem..? thanks.
I agree this can be confusing. IMAP accts will automatically Get New Messages but POP accts do not. We discussed making POP accts also automatically Get New Messages, at least on startup, but got opposition from some POP users who strongly felt "POP was not designed to work that way". As far as what users expect, most users Do expect to see new messages appear in their Inbox when mail is started. Having "Automatically download new messages" as a separate pref (not a sub pref) would be a potential solution, as someone mentioned. FYI, spec from when this was discussed is here: http://www.mozilla.org/mailnews/specs/threepane/GetMail.html
Scott, According to Jennifer's comments, should I log a new bug to change the sub pref of biff " automatically download any new messages " to be a separate or pref on its own? Or I can update the summary of this bug. When it is a separate pref on its own, will this be checked by default? Then currently we have biff checked by default with every 10 minutes. So won't we be back to what was complained earlier that POP users don't like to download messages all the time?
Whenever we implement this, I think, it should not be checked 'on' by default. Users interested can go and check it 'on' to take advantage of the feature.
>Whenever we implement this, I think, it should not be checked 'on' by default. Sounds good. Is there any reason "Automatically" download messages was tied to "Check for mail..." and not separate? Are there any problems with it being an independent pref? Reporter, does this solution seem ok?
So the pref "check mail at start up" will not change its current behavior. It will still check and just indicate if there are any new messages on the server. To have the messages download the user have to check " Automatically download any new messages" checked right?
the problem with it being separate is that I'm not sure it makes any sense. We would have: Check Mail at Startup Check Mail every x minutes Automatically download new messages If the first 2 are turned off, then what does it mean to have the 3rd one turned on? I'm sure there's some scenario I'm messing up here, but what if we had: Get Mail at Startup Check Mail every x minutes Automatically download new messages and then, make Check Mail every x minutes check at 0 (if there's a password remembered) as well as at x minutes. So, the scenarios would be: [x] Get Mail at startup [] Check Mail [] Automatically download would get mail on startup [] Get Mail at startup [x] Check Mail [] Automatically download Just does a biff (puts up green arrow) if the password is remembered and would catch the startup case as well. [] Get Mail at startup [x] Check Mail [x] Automatically download This would do a biff and get the messages if the password is remembered. So, the only problem this doesn't solve is if the user wants to just do a biff (no download) and doesn't want to remember their password. I'm not as worried about that case since I think most users will want to download their mail on startup and we provide other ways of checking mail if they don't want to. I'm sure I'm missing something or perhaps this can be arranged differently.
And, I mean for "Get Mail at Startup" to do what others have suggested which is to check and download mail and prompt for a password if necesary.
>If the first 2 are turned off, then what does it mean to have the 3rd one >turned on? D'oh So what you're proposing is basically changing "Check for new mail at startup" to "Get new mail at startup"? (Note: would be inconsist with IMAP prefs but that could be changed) Or, just leave the settings as they are and assume someone who has checked "Automatically download new messages" wants this on startup as well. I think this is a logical conclusion. If they want their messages pulled automatically whenever mail is checked, and they want mail checked on startup... won't they want the messages automatically pulled on startup?
[x] Check for new mail at startup [] Automatically download new messages at startup [x] Check for new messages every [10] minutes [] Automatically download new messages With some variation of wording, this is the most flexible system (for default POP account) we can offer to the user. Both "Automaticaly...." will appear only for POP accounts. It may look redundant, but it offers the maximum flexibility. For secondary POP accounts (non default POP account), we will turn 'off' the checkbox for 'Check for new mail at startup'.
Summary: [RFE] Automatically download new messages by default when checking mail at startup → [RFE] Automatically download new messagesby default when checking mail at startup
We already have automatic downloading pref. why have one more for start-up ? The "automatic download" should be enabled when we have selected either Check mail at start-up or on biff. The should appear in this order... [ ] Check for new mail at startup [ ] Check for new messages every [ ] minutes [ ] Automatically download new messages
If you are to push through with 're-implementing' or changing the current behavior my suggestion is this ----- [ ] Check for new mail at startup [ ] Check for new messages every [ ] minutes [ ] Automatically download new messages - Automatically download new messages is only available if one or the two preferences before it is selected. If none of the two is selected it should be greyed out - no checking for new mail or downloading is done in this configuration ----- [X] Check for new mail at startup [ ] Check for new messages every [ ] minutes [ ] Automatically download new messages - Automatically download new messages is selectable - as per current behavior a green down arrow is shown indicating new mail at startup - checking for new mail is done at startup but no downloading ----- [X] Check for new mail at startup [ ] Check for new messages every [ ] minutes [X] Automatically download new messages - as per current behavior a green down arrow is shown indicating new mail at startup - checking for new mail and downloading is done at startup ----- [ ] Check for new mail at startup [X] Check for new messages every [N] minutes [ ] Automatically download new messages - Automatically download new messages is selectable - as per current behavior a green down arrow is shown indicating new mail every N minutes - checking for new mail is done every N minutes but no downloading ----- [ ] Check for new mail at startup [X] Check for new messages every [N] minutes [X] Automatically download new messages - as per current behavior a green down arrow is shown indicating new mail every N minutes - checking for new mail and downloading is done every N minutes ----- [X] Check for new mail at startup [X] Check for new messages every [N] minutes [ ] Automatically download new messages - Automatically download new messages is selectable - as per current behavior a green down arrow is shown indicating new mail at startup, and every N minutes thereafter - checking for new mail but no downloading is done at startup, and every N minutes thereafter ----- [X] Check for new mail at startup [X] Check for new messages every [N] minutes [X] Automatically download new messages - as per current behavior a green down arrow is shown indicating new mail at startup, and every N minutes thereafter - checking for new mail and downloading is done at startup, and every N minutes thereafter just a suggestion =)
Roderick, Thanks a lot for listing out various scenarios. Here is the scenario that we will have trouble with : 1. I want to check the mail at startup and automatically download new messages 2. At the same time, I want to turn the biff on and don't want to automatically download new messages when biff is triggered. So, the problem is very similar to what is wanted in this bug. If we enable is for one, we take out some flexibility. Given that, and with no additonal efforts, the best scenario is to just retain what we have today. Just turn on biff and set the biff timer to some high value 999 minutes (16.65 hrs) and turn the Automatically download meessages. So, the biff is very unlikely to trigger on the user and at the same time new messages are downloaded at the startup. It is purely work-around or hack whatever you want to call it. Any solutions without complicating the issue are welcome.
Bhuvan brings up a good point. In addition, is it an acceptable UI design to have same level checkboxes determine whether another checkbox is enabled?
please read (in last update) : If we enable is for one, we take out some flexibility. as If we enable is for one, we take out some flexibility from the other. BTW, given other critical bugs we have in hand, we may not be able to get to this quickly.
I see the problem, in that case racham's suggestion would be better, that is [ ] Check for new mail at startup [ ] Automatically download new messages at startup [ ] Check for new messages every [10] minutes [ ] Automatically download new messages or a variation [ ] Check for new mail at startup [ ] Check for new messages every [10] minutes [ ] Automatically download new messages [ ] Only at startup - 'Only at startup' I think is self-explanatory Anyways this is a RFE, it is best that this be worked on later since there are I think more pressing bugs. The solution for now would be the 999 minutes timer hack or update the documentation to better describe the current behavior.
racham's proposal gives those most options and flexiblity and is prob the best solution (makes everyone happy) if/when this bug is fixed. Roderick's last idea is interesting, but as putterman mentions, it does seem odd to have checkboxes at the same level (which hence should be independent of each other) where one checkbox would need to be enabled/disabled based on other checkboxes.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3a) Gecko/20021212] (Last comment is dated 2001-10-11 :-|) In v1.3a, and probably previous releases, 1) The U.I. is like described in comment 30, which seems right for now as this is how the job is actually done by Messenger :-) 2) The "Automatically ..." is not greyed when the two "Check ..." are unchecked: this may be consistent for a U.I. (independent options) but is odd from a user point of view (Checking only the third option actually "achieves" nothing) :-( 3) If a 4th option is to be added (for more flexibility, etc), I would retain the proposal in comment 28, and not the variation proposed in comment 34. 4) In all cases, I support the idea that POP accounts should not be "Automatically ..." by default: especially because then there would be the issue of dealing with "Leave messages on server" also ! 5) Lastly, this bug summary should be updated to be more precise on what this bug is/will now be about. *At least, add a space between "messages" and "by" !
Summary: [RFE] Automatically download new messagesby default when checking mail at startup → [RFE] Automatically download new messages by default when checking mail at startup
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3) Gecko/20030312] At least my point 4) in comment 36 is still valid: I'd like the "Automatically..." to be disabled by default !
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4a) Gecko/20030401] After reading <http://www.mozilla.org/status/2003-04-18.html> (see "POP3 Mail Accounts")... I noticed the following: *bug 77202 comment 33: "we still want pop servers, by default, to download on biff." *bug 134158 comment 11: *Suggestion 1 ("Make the "Automatically download..." pref also apply to the startup check.") is currently implemented (as described in bug 134158 comment 26). (see comment 14, and comment 5) *Suggestion 2 ("Add another "Automatically download..." pref {...}") has also been discussed here. (see comment 28) *Suggestion 3 ("Rename "Check for new ..." to "Get new ..." {...}") has also been discussed here. (see comment 25) Then, I update my comment 36 (and comment 37) as follows: 1) The U.I. is like described in comment 30, which seems right for now as this is how the job is actually done by Messenger :-) --> This results from the fix (put the 3 options on the same level) in bug 134158. For this issue, the current bug looks like a duplicate of bug 134158. 2) The "Automatically ..." is not greyed when the two "Check ..." are unchecked: this may be consistent for a U.I. (independent options) but is odd from a user point of view (Checking only the third option actually "achieves" nothing) :-( --> This remains to be dealt with: see comment 35... 3) If a 4th option is to be added (for more flexibility, etc), I would retain the proposal in comment 28, and not the variation proposed in comment 34. --> I stand by this, as the best solution for point 2). 4) In all cases, I support the idea that POP accounts should not be "Automatically ..." by default: especially because then there would be the issue of dealing with "Leave messages on server" also ! --> Since it is stated in all 3 bugs that the "auto. download" is wanted, I "vote" for a RFE to have "Leave {...}" also checked by default ! (or a mean to check it manually in the account creation wizard, like the fix in bug 77202.) 5) Lastly, this bug summary should be updated to be more precise on what this bug is/will now be about. *At least, add a space between "messages" and "by" ! --> This was done; for now, I add the "POP3" keyword also... Additionaly, I suggest to: a) "move" (= drop) the initial subject to bug 134158. (or mark it duplicate) (I mark this bug dependent in the meantime.) b) Refocus the current bug to comment 28 RFE. (or file a new bug) c) File a new bug about "Leave messages on server" default/initial value. d) Hardware/OS may apply to All/All instead of PC/Windows_NT !? I can do all this myself if you want, but I need your point of view first.
Depends on: 134158
Summary: [RFE] Automatically download new messages by default when checking mail at startup → [RFE] For POP3 servers, make 'Automatically download new messages' work with 'Check for new messages at startup' too
mass re-assign.
Assignee: racham → sspitzer
Status: ASSIGNED → NEW
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Assignee: mail → nobody
QA Contact: sheelar → message-display
Summary: [RFE] For POP3 servers, make 'Automatically download new messages' work with 'Check for new messages at startup' too → For POP3 servers, make 'Automatically download new messages' work with 'Check for new messages at startup' too
Target Milestone: Future → ---
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago → 15 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.