Laptop user always works at both office and home, he may use proxy@intranet at office and direct connection at home. Evevytime he switches working place, the first thing he has to do is to reset the proxy manually, can mozilla detect current proxy and shift to the other setting automatically if current setting does not work? if so, laptop user does not have to reset the proxy any more. Found some relatived bugs in http://bugzilla.mozilla.org/show_bug.cgi?id=61691, but seems there is no identical bug, so file this and mark it block 61691

Bug 59969 contains some ideas and links to other bugs. Bug 43429 will solve most of the issues, but isn't about an auto-detection.

we can probably leverage the work that will be done to support PAC failover to solve this bug. marking as a dependency.

Auto detection as described, would not be the right way of doing this, in my mind. Assuming that you will lose connectivity w/ a proxy server because you switch networks is not a good assumption. Instead, better support for either OS "location" managers, or adding some kind of IP/network detction into an implementation of bug 88218 would make more sense, and be more robust.

currently, There are 3 optioins that mozilla user can choose to connect to internet, directly or use selected proxy, and use proxy set by pac. if mozilla can detect which option is better in everystartup, then use it, no matter what he chose in preference setting,

I got one idea for it, please advice. if user selected proxy (either by pac or manual) is failed, mozilla will try to connect it with direct connection. and since then, mozilla will use direct connect until 30 mins later, it will detect proxy again. this feature could be turned on by preferce settings.

just for discuss. (No prefercense option support)

add option in preference UI. darin, can you take a look?

dupe of bug 79662 ?

Comment on attachment 134300 [details] [diff] [review] patch 0.2 jerry, 1) i thought we agreed over irc that you would split this patch into two parts: one for the UI changes, and one for the necko changes. why combine the two? 2) we also discussed having ExamineForProxy return a list of nsIProxyInfo objects, which would include one extra element for the "direct" case. why did you decide against that? 3) i don't agree with this use of preferences to control the no-failover timeout. how about adding an extra method on nsIProxyInfo which can be called to mark the proxy object as invalid? that can in turn store some information in nsProtocolProxyService so ExamineForProxy will know to not hand out that "bad" nsIProxyInfo object the next time it is called (for up to X seconds). this would make much more sense in my opinion, and would only require very minimal changes to nsHttpChannel.cpp. you don't want to make big changes to nsHttpChannel because that means you'd also have to make big changes to every other protocol when you want those other protocols to support failover. failover should be as transparent as possible. clearly, each protocol that wants to use failover has to iterate over the list of proxies, but that should be the extent of the work required.

I'm uncomfortable w/ this type of extra logic. If we want to provide better support for switching networks, we have a lot of good RFE's that would make mozilla work in the described environment better. The 4xp design is pick a mode, and live with it. direct, manual or pac. If choicees 1 & 2 are not smart enough for you, write a .pac file that does what you want, and use choice 3. I think we should stick to that. If people want magic for the situations proposed, PAC would do that, assuming we did failover correctly in PAC per the spec, which we don't. (Bug 207633).