[go: nahoru, domu]

Open Bug 1330019 Opened 8 years ago Updated 2 years ago

"Auto-detect proxy settings for this network" setting doesn't work consistenly

Categories

(MailNews Core :: Networking, defect)

x86_64
Windows 10
defect

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: kjatwork, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161208153507

Steps to reproduce:

I setup TB to receive emails when starting, 2 IMAP and 2 POP3 accounts. The network settings are configured to auto detect proxy settings, because I run the portable version of TB in different locations.
I'm using TB portable and I configured TB to receive emails as soon as it is started. The network connection setting are auto detect proxy settings because I use TB in different environments.

If run in proxy network then receiving emails fails when TB is started and no emails are received (2 IMAP account are reported to time out). 
Then if I start receive email manually for each account I'm being asked to enter the corresponding password and all works fine.

If I launch TB in a network without a proxy all works fine as expected (I'm being asked to enter the password directly).

There is one (weird) exception in the proxy environment: if TB has been updated, then emails are received at the very first start. Then it behaves as described above.
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
Component: OS Integration → Networking
Product: Thunderbird → MailNews Core
I had a closer look to network monitor and found out that in a "proxy environment" TB tries to connect directly to the mail server when starting, which yields to timeout. Receiving emails manually always works (even directly after the connection failure) then socks proxy is being used and the password window is being shown.

Why TB does not use socks at the very first attempt to connect to the mail server?

And it would be interesting what happens when starting TB the first time after an update. Then the passwords are asked directly (I couldn't test it because I use the latest version 45.6.0).
TB Version 45.7.0 is being released. Can I do something during the update and first launch process to collect some data for narrowing down the problem?
I ran TB 45.6 and 45.7 with NSPR traces enabled to see the differences. Could provide the log files.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.