Closed Bug 529364 Opened 15 years ago Closed 13 years ago

[TB3] "check for new messages at startup" (pref) not done, if no password stored neither "automatically download" pref is checked

Categories

(Thunderbird :: Preferences, defect)

defect
Not set
major

Tracking

(thunderbird3.0 wanted)

RESOLVED DUPLICATE of bug 533083
Tracking Status
thunderbird3.0 --- wanted

People

(Reporter: bdrline07, Unassigned)

References

()

Details

(Keywords: qawanted, Whiteboard: dupme. See comment 27 for clear description [gs])

Attachments

(4 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4) Gecko/20091016 SUSE/3.5.4-1.1.2 Firefox/3.5.4 GTB5
Build Identifier: 3.0b4

openSuse 11.2
Thunderbird 3.0b4

Thunderbird 3.0b4 does not automatically get new mail on startup, even though following settings are in place:

x Check for new messages at startup
x Automatically download new messages

One needs to click the Get Mail button to generate this mail client/server activity.

I believe the adjustable:

x Check for new Messages every X minutes

... seems broke as well in this beta.

A TB problem, or perhaps an openSuse problem?

Reproducible: Always

Steps to Reproduce:
1. When starting TB it should automatically check for new POP3 email, if configured correctly.
2.
3.
Actual Results:  
It appears in busy mode for 30 or 4 seconds, but it is not checking for new mail.

Expected Results:  
Upon startup, it should have checked pop3 mail server I have it configured for.

I initially did a clean install of openSuse 11.2 RC1
  (this is when I first got TB3.0b4)

I did upgrade to 11.2 RC2

I did upgrade from RC2 to official openSuse 11.2

Reported in openSuse forums as well.
Patrick you have both :

check at startup and check every XX minute set right ? What happens if you disable one, does the other one work ?
I just went thru a 10 minute adjustments of settings and restart of TB each time.  I've got no changes, never did it try to get new mail at startup.

This time, I timed it's program 'startup busy', which runs about 30 seconds, or so mouse cursor shows...

Weird.

this really isn't that slow of a laptop:
  Intel(R) Core(TM)2 Duo CPU T5550 @ 1.83GHz  with 4G of reasonably fast DDR RAM.
I was mistaken to a degree, my TB will actually check for new mail every 4 minutes, as I currently have it set, it just won't check for new mail at startup.
unfortunately, confirming for Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091117 Shredder/3.0.1pre

We don't download new pop3 msgs upon startup (did not test imap yet), with following settings in my case
[x] download at startup
[x] download every 10 min
[x] automatically download
[x] leave messages on server (for good)
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: x86 → All
Whiteboard: dupme
Version: unspecified → 3.0
Severity: minor → major
on the clean install i'm currently using (well, I THINK it's clean)
this has easy workaround, but for (business & private) users who rely on the automatical download at startup this might be quite annoying
Flags: blocking-thunderbird3?
This works for me on:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091120 Shredder/3.0.1pre

with the steps in comment 4.

I'm pretty sure we'd be seeing more bugs/duplicate if we had broken this in nightlies, so my guess there's another setting that is at fault or Thunderbird hasn't been able to contact the mail server on startup.
Flags: blocking-thunderbird3? → blocking-thunderbird3-
Keywords: qawanted
similar Bug 352107 - "Check for new messages every XX minutes" only works once a startup or manual check has been done
(In reply to comment #7)
> This works for me on:
> Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5)
> Gecko/20091120 Shredder/3.0.1pre

Hmm. I'm still seeing this on *Windows* in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091120 Shredder/3.0.1pre

Could someone test this on windows with steps as below? (please say when you first installed the build you're running with)

> with the steps in comment 4.
That's just settings, here's steps:

STR
1 clean install, fresh profile, change account settings as in comment #4, smart folders view
2 compose pop3 test mail, send
3 quickly close TB
4 re-start TB

Actual
- TB is doing something, but the new msg isn't received

Expected
- immediately upon startup, TB should now automatically get and download your test msg to inbox

> I'm pretty sure we'd be seeing more bugs/duplicate if we had broken this in
> nightlies

maybe not, my feeling is that this broke only within the last week or so, and it must be before 20091117 when I first saw this

> so my guess there's another setting that is at fault
my "fresh install" was also done a week ago or so, I did not install again to test, just getting the updates.

> or Thunderbird hasn't been able to contact the mail server on startup.
No, it's not that.
Summary: Thunderbird 3.0b4 does not automatically get new pop3 mail upon startup → Thunderbird 3.0.1pre does not automatically get new pop3 mail upon startup ("check for new messages at startup")
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091121 Thunderbird/3.0 (rc1 build 3)

OK (sigh), I went to the trouble of installing once more, so here's more precision on this bug -> confirming on rc1 build 3 on windows.
Steps have changed (see below), especially I'm no longer changing the default setting for "Automatically download new messages", which is OFF by default (bug 

This is very bad UX, as with a default install, we will never get new messages at startup (and not even after x minutes, at least for my check with x=1min)
-> requesting blocking for the final release

Most of the steps below are probably unrelated to this bug, but I'll include every detail just to be on the safe side.

STR

1) fresh install (tb3 rc1 build3), don't make default client, uncheck(!) "start thunderbird after install" (i. e. do NOT let it start automatically)
2) create new profile TB3RC1_profile (created with RC1-thunderbird.exe -p)
3) fire up tb (thunderbird.exe -p TB3RC1_profile -no-remote)
4) create one pop3 account with autoconfig, immediately as requested, but
- don't enter or save password (! important)
- don't cancel to avoid potential trouble

Default settings are now like this:

[x] check for new messages at startup
[x] check for new messages every [10] min
[ ] automatically download new messages <-- this is unchecked by default, which I think will make this bug very frequent!!! (Bug 516950)
[ ] fetch headers only
[x] leave messages on server
  [x] for at most 14 days
  [x] until I delete them

5) from tools > account settings > your account > server settings,
change evil default settings that will bring big trouble to many users (because they will have no clue that their mail gets deleted from server after 14 days):
- uncheck "for at most 14 days" and "until I delete them"
6) for testing purposes, change "every [10] mins" to "every [1] min" (could this do harm??? if yes, feel free to leave it at 10 mins and wait long, I refuse to do this)
7) quickly write short test message to yourself, send (! important)
While you carry on with this test, always make sure there are new msgs on server!
8) close tb, wait some secs so that it's really shut down orderly
9) open tb

Actual result
- new messages are neither gotten nor downloaded at startup (no biff and no password prompt are the proof) -> this bug

10) wait until tb should get new msgs automatically (after 10 or 1 min, see
step 6)
- NO new messages are received automatically, ever (wait as long as you please).

Please note:
- I'm on Windows XP
- I only tested the 1min case, dunno if changing to 1min can break anything
- I'm always closing tb only with window's close button [x] in upper right corner
*** Important!: You will only see the wrong behaviour if "automatically download new messages" was NEVER EVER checked. As soon as you check it, restart tb, then uncheck it, everything will work as expected:
- on startup and every x min, you will only get the one-line new mail notification from systray ("you have 7 new msgs", no details)
- but no messages will be downloaded into tb msg list because of the setting
(However, in spite of changing the setting, I still can't get it to work on my previous clean install, as reported earlier in this bug)

11) Now change the following setting:
[X] automatically download new messages (check/enable this)

12) wait some more (I don't remember, but I think tb still doesn't get anything automatically)
13) close tb, wait, restart tb
-> only now you get the password prompt for getting new messages at startup

My current conclusion from all this is:
- Fix bug 516950, which for most people will (hopefully) avoid this bug:
-> "automatically download new messages" should be checked by default (at least for pop3)
Flags: blocking-thunderbird3- → blocking-thunderbird3?
Blocks: 516950
Thomas D is right. If you don't have automatically download new messages set, and you don't have the password remembered, but you do have check for new mail on startup, we don't prompt you for your password on startup. We're not going to block for this because the fix for bug 516950 will fix it for the vast majority of users. We'd take a simple fix for 3.01, I believe, though I wouldn't block on it for 3.0x either.
Flags: blocking-thunderbird3? → blocking-thunderbird3-
(In reply to comment #12)
> (A) If you don't have automatically download new messages set,
> (B) and you don't have the password remembered, 
> (C) but you do have check for new mail on startup,
> we don't prompt you for your password on startup.

David, is next right?
  Bug 458625 fixed A==true && B==false && C==true case.
  This bug is for no password prompt issue when A==true && B==TRUE && C==true.

If yes, why problem of Comment #4 occurred? Bug 458625 was fixed on 2009-08-26, and I changed it to verified on 2009-09-14 based on test results with Shredder and Sm 2. So I think Bug 458625 is already resolved by Tb3 2009-11-17 build.
Password is not prompted unless password was prompted once by manual Get Msgs, even if "automatically download" is checked(A==false case)? 

> (Copy of Comment #4)
> unfortunately, confirming for Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.9.1.5) Gecko/20091117 Shredder/3.0.1pre
> We don't download new pop3 msgs upon startup (did not test imap yet), with
following settings in my case
> [x] download at startup
> [x] download every 10 min
> [x] automatically download
> [x] leave messages on server (for good)
My recollection is that bug 458625 occurred even if you had the password remembered, and that was the case that I fixed. But I could be wrong.
"no password remembered" case is problem of Bug 533083?
"Automatically Download" should ONLY be set if "Leave messages on server" (with no "delete after..." option checked) is also set.  Downloading -- then deleting -- a user's messages is a BAD[tm] thing to do.
 Michael A. Pasek, get POP3 log with next value and check flow.
> NSPR_LOG_MODULES=POP3:5,nsSocketTransport:5,nsHostResolver:5
> http://www.mozilla.org/projects/netlib/http/http-debugging.html
> https://wiki.mozilla.org/MailNews:Logging
Same issue as Bug 533083?
If Tb's fault is seen in log, attach log file, please(never paste, please).
I have observed what was probably the problem noted in Bug 533083 when I cancelled the password prompt (status at bottom of window shows "Connect: host contacted, sending login inf..." -- but there's no active TCP connection).  I did have "check for new messages at startup" set; that was with TB 2.0 on MacOS 10.5.8, and it appears to have been fixed in 3.1a1pre.

My comment was more in relation to comment #12 -- that the "fix" for Bug 516950 might be an easy workaround for this problem.  However, the "fix" for Bug 516950 ignores the fact that the "default" settings are OK for some users, while potentially devastating for advanced users; see Bug 531092. 

I'll admit the current "defaults" are an improvement over the settings in TB when I first tried it; it downloaded and IMMEDIATELY deleted the messages that were on the server.  Fortunately, it was a test account that I had just set up on the server, and the messages were just "test" messages.

Thanks for the logging links.  It probably would have taken me MONTHS to find that info! I'm sure they'll come in handy.  However, I don't think I'll be able to provide the necessary logs as I do not experience the problem noted in this Bug Report.  This is on Mac OS 10.5.8 using TB 3.1a1pre, with server settings:
[x] check for new messages at startup
[ ] check for new messages every [10] min
[x] automatically download new messages <-- this is unchecked by default, which
[ ] fetch headers only
[x] leave messages on server
  [ ] for at most [7] days
  [x] until I delete them

Sorry for the longish comment....
(In reply to comment #18)
> This is on Mac OS 10.5.8 using TB 3.1a1pre, 

Please read "OSX" section in http-debugging.html(MailNews:Logging doesn't have guide for OSX user). As you use Mac OS 10.5.8, take care on next in http-debugging.html. 
> [Note:] If you are using Mac OSX 10.3 or later, then you're most likely using
> the bash shell instead of tcsh. In that case replace setenv with export. 

> as I do not experience the problem noted in this Bug Report. 
> with server settings:
> [x] check for new messages at startup
> [ ] check for new messages every [10] min
> [x] automatically download new messages <-- this is unchecked by default, >(snip)

You said that your problem occurred even with "automatically download new messages" checked in your Comment #4, didn't you?

Bug 533083 doesn't refer to "automatically download new messages" setting, so Bug 533083 may be for "automatically download new messages" unchecked case. If so, and if your problem doesn't occur with "automatically download new messages" checked, your original problem may be Bug 533083.
If your problem occurs only with "automatically download new messages" unchecked and "no remembered password", get POP3 log with "automatically download new messages" unchecked, please.
> You said that your problem occurred even with "automatically download new
> messages" checked in your Comment #4, didn't you?

No, that wasn't me (although I _did_ copy the text for the "server settings" from Comment #10; the writer of that comment is also the writer of Comment #4).  I did modify the actual settings to reflect what I have configured. 

> Bug 533083 doesn't refer to "automatically download new messages" setting, so
> Bug 533083 may be for "automatically download new messages" unchecked case.

I don't have "check for new messages every xxx min" enabled, but I DO have "automatically download" enabled.  I just updated Bug 533083 to note that I couldn't reproduce the problem.  However, I can reproduce it _if_ I disable "Automatically download messages".  In that case, the problem noted in Bug 533083 _does_ occur (bogus network connection, no password prompt) -- I'll add another comment to 533083.

> If your problem occurs only with "automatically download new messages"
> unchecked and "no remembered password", get POP3 log with "automatically
> download new messages" unchecked, please.

Actually, "my problem" is that the default is to delete messages from the server.  However, since the problem noted in this bug report DOES occur for me with "Automatically download new messages" unchecked, I'll get that POP3 log and a 'tcpdump' capture.  Will attach when available.
Attached file POP3 log
POP3 log - TB 3.1a1pre
Attached file tcpdump
'tcpdump' of spurious network connection, as noted in Bug 533083 (will attach logs there, too).
Attached file ShredderDebug output
Debug output from console/terminal.
I didn't get the HTTP log (didn't think there'd be too much HTTP going on in a POP3 session).  However, if there's "internal" TBird stuff that would get recorded that doesn't show up in the "ShredderDebug" output, I could get the HTTP log, too.
(In reply to comment #21)
> POP3 log - TB 3.1a1pre

> -1603840224[80a920]: SEND: AUTH
> -1603840224[80a920]: Entering NET_ProcessPop3 26
> -1603840224[80a920]: POP3: Entering state: 3
> -1603840224[80a920]: RECV: -ERR Unknown AUTH method
> -1603840224[80a920]: POP3: Entering state: 27
> -1603840224[80a920]: POP3: Entering state: 28
> -1603840224[80a920]: SEND: CAPA
> -1603840224[80a920]: Entering NET_ProcessPop3 63
> -1603840224[80a920]: POP3: Entering state: 3
> -1603840224[80a920]: RECV: -ERR Invalid command; valid commands:  USER, APOP, AUTH, QUIT
> -1603840224[80a920]: POP3: Entering state: 29
> -1603840224[80a920]: POP3: Entering state: 30
> -1603840224[80a920]: POP3: Entering state: 5
> -1603840224[80a920]: ERROR: 4013
> -1603840224[80a920]: POP3: Entering state: 24
> -1603840224[80a920]: POP3: Entering state: 25

Your problem is probably different from Bug 533083, because your server returns -ERR to CAPA after "-ERR to first AUTH by Tb", and Tb's log of "ERROR: 4013" after it is written in your case, although similar issue to Bug 533083 is probably involved in your case(no password prompt if login fails when password is not saved).
> Your problem is probably different from Bug 533083, because your server returns
> -ERR to CAPA

That doesn't make much of a difference. The AUTH and CAPA is mostly needed to know which login types are supported. If no better ones are available, we use the standard insecure one, but we still get the password just the same in both cases.
>> Your problem is probably different from Bug 533083, because your server returns
>> -ERR to CAPA
>
> That doesn't make much of a difference.

Shouldn't make any difference.  The response is as noted in RFC 2449; TBird should then "fall back" to the set of commands/responses described in STD0053.

In summary, with "Check for new messages at startup" ENABLED, "Check for new messages every xx minutes" DISABLED, and NO password saved, two different behaviors are noted:
  a) If "Automatically download new messages" is NOT enabled, the problem noted in this bug report (and Bug Report 533083) occurs -- messages are NOT downloaded at startup (and no password prompt occurs);
  b) If "Automatically download new messages" IS enabled, the problem noted in this bug report does not occur -- new messages are downloaded after the password is entered into the prompt.

For case "a", the bogus server connection noted in 533083 occurs, and the connection is immediately closed with FIN.  For case "b", there are two variations of the connection.  Both cases start out with the connection, invalid AUTH command (it does not include one of the methods noted in RFC1731 -- the server DOES support the "AUTH" command, as indicated in its negative response), and CAPA.  The variation depends on whether the user enters a password or clicks "Cancel":
  1) If the user clicks "Cancel" to the password prompt, the connection is closed with FIN -- no messages are downloaded at startup (which is to be expected, since the client clicked "Cancel" to the
request for information needed to complete the download of messages);
  2) If the user enters a password (and clicks "OK"), the connection continues with "USER", "PASS", etc.
Whiteboard: dupme → dupme. See comment 27 for clear description
(In reply to comment #27)
> In summary, with "Check for new messages at startup" ENABLED, "Check for new
> messages every xx minutes" DISABLED, and NO password saved, two different
> behaviors are noted:
>   a) If "Automatically download new messages" is NOT enabled, the problem noted
> in this bug report (and Bug Report 533083) occurs -- messages are NOT
> downloaded at startup (and no password prompt occurs);
>   b) If "Automatically download new messages" IS enabled, the problem noted in
> this bug report does not occur -- new messages are downloaded after the
> password is entered into the prompt.

Thanks for summary.
Following is a part of bug 533083 comment #6 which was posted after my previous comment.
> I lied. The problem DOES occur for me, but only if "Automatically download
> new messages" is NOT checked in "Server Settings".

By the way, comment #4 by not-you(sorry for my confusion) was confirmation of what problem? Comment #4 is "Leave messages on server" specific issue?
Setting dependency to bug 533083 before duping, for ease of search and tracking.
Depends on: 533083
>Following is a part of bug 533083 comment #6 which was posted after my previous comment.
>> I lied. [...]

Yes.  I had looked at 533083 and tried to recreate those symptoms, but I was always prompted for a password.  I had updated 533083 to corroborate that the "bogus server connection" occurred for me, too.  It was only after I had come back to this bug report and read comment #19 that I thought to try the same sequence with "Automatically download new messages" disabled -- and discovered the "no password prompt" problem noted previously.

> By the way, comment #4 by not-you(sorry for my confusion) [...]

That's OK; there are a lot of comments here!

> [...] was confirmation of what problem? 

I believe Thomas D was confirming that -- despite enabling "Check for new messages at startup", "Check for messages every xx minutes", "Automatically download new messages", and "Leave messages on server", he -- using the build described -- experienced the problem noted by the original reporter.


> Comment #4 is "Leave messages on server" specific issue?

No, I don't think so; I don't think that setting has anything effect on this problem.  Wa-ka-ri-ma-sen (however you spell it in Roman characters) for creating more confusion...I was merely attempting to reinforce that commenter's feelings about the "default" settings -- which were probably clearer in Comment #10:
> 5) from tools > account settings > your account > server settings,
> change evil default settings that will bring big trouble to many users (because
> they will have no clue that their mail gets deleted from server after 14 days):

I think the commenter further explains "evil default settings" in 531092 -- I happen to agree with him.

Just out of curiosity, which bug will this one be "Duplicate"d to ?  Hopefully not 533083, because that only describes an erroneous connection to the server, not the lack of a password prompt.  If the "bogus server connection" is fixed, the problem noted when "Automatically download new messages" is NOT enabled may still occur.

Since I'm using MacOS, and the early reporters of this problem reported it on Windows, I can't repeat my tests on Windows, but I suspect that if this problem DID occur with "Automatically download new messages" enabled (as noted in the first few comments), that problem has since been corrected.  I think Comment #10 noted this:
> *** Important!: You will only see the wrong behaviour if "automatically
> download new messages" was NEVER EVER checked. As soon as you check it, restart
> tb, then uncheck it, everything will work as expected:

My experience is slightly different.  If I uncheck (disable) "Automatically download new messages", then quit and restart TB, the "wrong behaviour" returns.  In other words, if "Automatically download new messages" is disabled at startup, the problem occurs.

Can someone with Windows who observed this problem with "Automatically download new messages" enabled at startup confirm (or refute) that the problem has been corrected (or never really occurred) for that case ?
Suggested changes for Bug 533083 (see attachment 417378 [details] [diff] [review] in Bug 533083) appear to fix this problem -- assuming that the original reporter was mistaken (comment #0), and "Automatically download new messages" was NOT enabled (i.e., the configuration is that described in comment #10).
Based on comment 27, filed bug 535943 "Automatically download messages" shouldn't have an influence on prompts
Thru openSuse's Yast my TB was updated to ver 3.0 about a week ago.

Same problem exists, it will not check for new email at startup.

Though I don't believe I saw a fix comment for the busy 30 to 40 second mouse I also addressed here, in version 3.0 'mouse busy' is now finished as soon as TB is fully up on my monitor.  Nice correction.
I confirm the same bug under Fedora 12 x86_64 (TB 3.0 packaged from RedHat).

My server settings:
connection security [SSL/TLS]
[x] use secure authentication
[x] check for new messages at startup
[x] check for new messages every 5 minutes
[x] automatically download new messages
[ ] fetch headers only
[x] leave messages on server
[x] for at most [30] days
[ ] until I delete them
[ ] empty trash on exit
So, there's a bit of disagreement in this bug, but I'm currently experiencing a regression from TB2 which I think is covered by this bug.

With "check for new messages at startup" checked and automatically download new messages *NOT* checked, and *no* password remembered, TB2 would prompt me for a password at startup and inform me when there was new email.

TB3 does not do this with the same settings. This is most annoying because I must go and choose each inbox and then click "get mail" and then click the next inbox, and click "get mail" for all inbox. I have 3 and I do not enable (or want) "combined magic inbox" stuff.
I was searching for a solution in the forums, and came across the getsatisfaction.com/mozilla_messaging/ where other people were having a similar problem as I.

Someone directed me to this page to leave a comment.

Windows VISTA  32 bit OS
Thunderbird 3.0.1
DELL Inspiron 1525 Laptop

I open Thunderbird and nothing happens with downloads.   5 minutes after opening up TB, all mail starts to download.

TB has my passwords stored.
I have 4 POP accounts that are downloaded into TB.
The "Server Settings" are all identical.

I have added an "Attachment" at the top of this page entitled "Account Settings Screenshot" so that you can see what I have selected and de-selected.

professor_km@cox.net
Kent Musgrave
(In reply to comment #37)
> [...] Windows VISTA  32 bit OS
> Thunderbird 3.0.1 [...]
> I open Thunderbird and nothing happens with downloads.   5 minutes after
> opening up TB, all mail starts to download.
> 
> TB has my passwords stored. [...]
> The "Server Settings" are all identical.

Thanks for the info.  This would seem to corroborate the experiences of the original bug reporter; i.e., using Windows, and no check at startup even WITH "Automatically download new messages" configured.  Would it be possible to gather the "POP3:5" log as described in Comment 17 (no need for the HTTP logging) ?
Hi all,

I didn't get this bug in version 3.0 (the original release); but am getting it now with most up to date version (created new profile and copied mail across).

I use local folders only as I only use Tbird for one account (yahoo). I use 'All Folders' view as do not like the smart view.

Windows XP Pro 32 bit (fully updated)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1

My account settings (server settings):

[x] Check for new messages at startup
[x] check for new messages every 3 minutes
[x] Automatically download new messages
[ ] Fetch headers only
[x] Leave messages on server
--- [x] for at most 31 days
--- [ ] until I delete them
[x] Empty deleted folder on exit

Addons =
1) British Dictionary
2) Copy Plain Text 0.3.3
3) MinimizeToTray 0.0.1.2006102615+
4) Update Notifier 0.1.5.5

Default Theme used

Master password prompts at beginning (i.e. when I first load TBird).

NOTE: I also find that the auto check every '3' minutes does not work ! So therefore am having to check mail manually at the moment :(
Correction: It does check mail every 3 minutes.
There are a lot of comments here and they do not all address the same issue, so things tend to get confusing. 

The following describes what in fact is happening with the most current release:

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1

under the following circumstances for an installation with *several* POP3 accounts and *one* IMAP account:

Two of the POP3 accounts in TB are configured as follows:

[x] Check for new messages at startup
[x] Check for new messages every 10 minutes
[ ] Automatically download new messages
[ ] Fetch headers only
[ ] Leave messages on server
--- [ ] for at most 7 days
--- [ ] until I delete them
[ ] Empty deleted folder on exit

The IMAP account is configured as follows:

[x] Check for new messages at startup
[x] Check for new messages every 10 minutes

Passwords are configured to be NOT remembered on ALL accounts.

This implies the following behaviour of TB at startup: Prompt for passwords for the two PO3 accounts as well as for the IMAP account in order to check for new mail - this was correctly handled in TB 2.

In TB 3.0 (3.0.1) this is different: At startup, it prompts for the password of the IMAP account, but does NOT prompt for the POP3 account passwords. Also, when waiting for the "Check for new messages every 10 minutes" action, it does NEVER prompt for the passwords, implying that it does not check for those accounts as long as it does not have the passwords.

If the manual action "Get Mail" is performed, it will prompt for passwords and from that point on correctly check for mail on the server and indicate when new mail is available (I did not measure the interval though, but this has no relevance here).

In Comment 30 the following request was made: 

> Can someone with Windows who observed this problem with "Automatically
> download new messages" enabled at startup confirm (or refute) that the
> problem has been corrected (or never really occurred) for that case ?

I tried this option, too (Windows 7 Professional). In my version of TB (3.0.1) it will definitely prompt for passwords for the corresponding accounts at startup when "Automatically download new messages" is enabled additionally to the enabled options as listed above.

In other words, the bug consists in that TB 3 (3.0.1) does not prompt for a password at startup for POP3 accounts when it should do, as the option "Check for new messages at startup" in combination with unsaved passwords requires the password(s) to be requested from the user, in order to check for mail.

It should be relatively easy to locate this in the source code and find the reason.
(In reply to comment #41)
> It should be relatively easy to locate this in the source code and find the reason.

It was.  The problem now is determining:
  a) Whether or not you should be prompted for your password; and,
  b) Whether or not you should be notified of errors during the "Check for new messages at startup".
See Comment #31 and the bug referenced therein.
(In reply to comment #41)
....
> If the manual action "Get Mail" is performed, it will prompt for passwords and
> from that point on correctly check for mail on the server and indicate when new
> mail is available (I did not measure the interval though, but this has no
> relevance here).
> 

My apologies Michael if I have mis-understood but I am finding that TB3.02 does not prompt for a password when I click 'Get Mail'. It does connect and check for messages. I remember it did this in 3.0.1 as well.

Pete

Yahoo account is POP3? Plus I am on XP Pro 32-bit. Unsure if the latter would make any difference?
(In reply to comment #42)

>   a) Whether or not you should be prompted for your password;

If the option 'Check for new messages at startup' is enabled it is obvious that the user needs to be prompted for a password. Otherwise this option can not be fulfilled and hence makes no sense.

b) is obvious too. If there are errors, user need to be verified, for the same reasons.
- Not sure if it was mentioned above (that is a lot to go through), but the Get Mail button also doesn't work in this case.. I have two accounts a gmail IMAP account and another POP3 account .. Get Mail works only for Gmail... BUT if I manually select the account from teh Get Mail dropdown - it works!
If you chose to remember the password when asked when manually getting the mail - it still won't get mail on startup and it still won't work with the general Get Mail button press.
The  key to triggering the propblem is not remembering the password at time of account creation. Checking remember password later is no good - you won't need to enter the password for manual get mails the explicitly chose the account to get mail for.. but startup and 'global' Get Mail will always ignore the POP3 account.
Hi, seems linked to the above. I use TB for a single POP3 Yahoo account which if I select (i.e. the inbox) and click on Get Mail - TB does download any messages.
Summary: Thunderbird 3.0.1pre does not automatically get new pop3 mail upon startup ("check for new messages at startup") → [TB3] "check for new messages at startup" (pref) not done, if no password stored neither "automatically download" pref is checked
Not sure this solve the problem in all the cases reported, but surely in mine!
The trick seems to be the "Tools\Account Settings...\Account Actions\Set as Default" setting:
http://forums.mozillazine.org/viewtopic.php?f=39&t=1632695&sid=d0b96992f2941ed724a5c666a150737c&start=15
(In reply to comment #47)
> Not sure this solve the problem in all the cases reported, but surely in mine!
> The trick seems to be the "Tools\Account Settings...\Account Actions\Set as
> Default" setting:
> http://forums.mozillazine.org/viewtopic.php?f=39&t=1632695&sid=d0b96992f2941ed724a5c666a150737c&start=15

Following these (see post I linked to below) instructions it worked for me :D

http://forums.mozillazine.org/viewtopic.php?p=8579725&sid=f5eba231a3e0913f6ab3ce73653beef9#p8579725

Windows XP Pro 32 Bit (latest TBird)

Thank you Mauro !
Is there any chance that this will be rectified in TB anytime soon?
Whiteboard: dupme. See comment 27 for clear description → dupme. See comment 27 for clear description [gs]
The getsatisfaction report points out that it does for for IMAP, just not for POP. That's not logical indeed.
(In reply to comment #50)
> The getsatisfaction report points out that it does for for IMAP, just not for
> POP. That's not logical indeed.

Yes, another bug should be filed so that case can be corrected.  Since IMAP doesn't have "Automatically download new messages", the "Synchronize the most recent XX days" setting could be used; IMAP shouldn't prompt for a password if that is set -- and those nasty prompts/alerts will be suppressed!    ;-)

In all seriousness, fixing this case will be harder now that non-password authentication methods work (or work better).  "GetPasswordPromptRequired" -- as far as I can tell -- was never updated to accommodate non-password authentication.  It doesn't look like the "pre-flight" checks for biff accommodate non-password authentication either; "GetServerRequiresPasswordForBiff" in "nsMsgIncomingServer.cpp always returns TRUE, nsImapProtocol.cpp returns TRUE if the user isn't already authenticated.
marking as dup.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: