User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Build Identifier: Thunderbird 1.5 20051025 If a proxy is used for HTTP, but not for IMAP, and "use this proxy server for all protocols" is selected, IMAP will not work. Maybe it is user error, but generally in firefox, the "use this proxy server for all protocols" is selected to get ftp etc through the proxy. Selecting the same option here gives puzzling failures. Maybe some sort of distinction between mail protocols and http type protocols would be good. Reproducible: Always Steps to Reproduce: 1. Add a proxy server 2. Click "use this proxy server for all protocols" 3. Try to access mail through IMAP Actual Results: Inability to access mail Expected Results: access mail
I think this is not minor. When a proxy is selected in preferences, even smtp does not work. And the error message given by Thunderbird make it look like the network is down without giving the user (or administrator) any hint that it might be incorrect proxy settings.
This is doubly weird, too, because if you change to the "broken configuration" setup, then there are no connectivity problems until you close Thunderbird and restart Thunderbird. (See below.) So a user who "remembers" to use an HTTP proxy gets the added benefit of NOT BEING ABLE TO CONNECT the next time he runs Thunderbird. (In other words, this bug is only reproducable for me after a restart of the mail client, which is not "always.") I came accross this with two basically identical workstations -- one connected fine, the other had some problems. I snooped my IMAP server, and found out that the "broken configuration" computer was contacting the IMAP server on the http proxy port number (3180) instead of the IMAP port number, 143. This tipped me off that by selecting an HTTP proxy in Thunderbird, it will attempt to contact the IMAP server through the proxy. As I read this bug report, I tried to mess with the settings until I could say what is reproducable and what wasn't. At one point, I selected Manual, "Use this proxy server for all protocols." (In fact, this is what I had done a few days ago.) By selecting this option, IMAP would continue to work until I shut down Thunderbird and restarted.... but then Timeout contacting imap.example.com. Switching back to only the HTTP proxy (no SSL), things seem to work as expected. Now I can see web images in emails, and I can of course get IMAP mail as usual. Please confirm this bug. Windows 2000. Thunderbird 220.127.116.11 (latest). Workaround: DO NOT SELECT MANUAL PROXY and "Use this proxy server for all protocols."
This is clearly a misleading interface problem. Checking the "Use ... for all" checkbox changes the behavior of the listed protocols *but also of unlisted ones*.
I can confirm this bug on Thunderbird 18.104.22.168 on Windows XP. It is not only misleading, it is broken, since it apparently tries to proxy un-proxiable protocols like SMTP/POP/IMAP etc. Since the default behavior of a fresh install is to fetch a HTML page through HTTP in the preview pane, people in corporate environment will have to either not check "use this proxy for all protocols" or disable the default behavior (loading of the page in the preview pane).
The problem is when you do this, the SOCKS server is set as well, and that controls the mail protocols. Since an HTTP proxy cannot be (by definition a SOCKS proxy) you are pointing all your mail protocols to an unusable port. I'm working on a fix for this via FF3. If there is a general schedule for this product, please let me know.
If you mean tb3, here's the schedule: https://wiki.mozilla.org/Thunderbird:Thunderbird3:Schedule
->NEW This would require a fix to the connections (proxy) panel, which is cloned from FF3, which has a couple of related nasty bugs that I found. What's the approach here, do we want to get FF3 cleaned up, and then port the fixed GUI, or do we want to just fork the UI by fixing this now, and merge back the other fixes later? I've got checkin privs, but I need to get up to speed on the brave-new-world processes, so help here would be appreciated.
That depends on what you want to do. The proxy dialog is a fork of the firefox one already so if something needs fixing only UI wise it doesn't really matter which one to fix first (though we do try to stay close to firefox where applicable). If it requires core changes, get it into firefox first.
Only changes to connection.xul and connection.js. No fixing of core code. Is that what you mean?
Yes, only "UI changes" then.
Is bug 377865 truly a duplicate as suggested at https://bugzilla.mozilla.org/show_bug.cgi?id=377865#c15? It seems to me that 377865 could be more about proxy implementation than UI
Sounds duplish to me.
Transferring info from bug 377865 ... (In reply to benc from comment #12) > From the discussion in this thread, what I suspected (that the proxy config > in thunderbird needs to be re-factored), well that's pretty obvious now, > from the use cases provided. Next to Darin, I probably understand proxy > better than most, and I can't tell what is going on in TB. > > A couple problems: > > 1- The manual dialog was designed for Mozilla. In many ways it slightly out > of date for Seamonkey and Firefox. It was never intended to focus on the > needs of Thunderbird users. > > 2- There is no documentation, that I am aware of. When I worked for > Netscape, I was a proxy tester for browser. The mailnews features had no > equivalent. > > So, I've started to draft a description of proxy in the context of TB... You > can find it at: > > https://benc.fogbugz.com/default.asp?W58 > > If you want to read the draft and add comments, use the email address on the > page. (In reply to jenzed from comment #14) > I've emailed Benc and asked if we can transfer / copy his page to MDN. > > There are some existing MDN docs that might be useful: > > Proxy UI: https://developer.mozilla.org/en/Proxy_UI > Proxies in Necko: https://developer.mozilla.org/en/Proxies_in_Necko