I think many who work the "Networking" components have been surprised at the number of "localhost" and "ofline/online" bugs that have been filed in the Mozilla 0.x track. Pre-mozilla 1.0 networking UI is build on the Navigator design, which implicity assumed that users had one network point of entry in a session. There is support for going offline <-> online, but only for the same network. (Basically people would unplug from the lan, go home and dial into the same lan). However network environments are more complicated and robust now. For example, to access the Netscape Campus from home, I actually change network interfaces three times: DHCP assigned LAN address, DHCP assigned PPP over Ethernet (DSL "dialup"), DHCP assigned VPN address. If mozilla is to work better in this environment, several other network configuration features need to be added: 1- PAC menu selection. Rather than force a typed change to PAC files, we should store a list of PAC URLs, and allow menu selection. 2- Configurable "default domain" for name resolution. DHCP is not configuring my default domain, so it remains the original domain even when I am in the Netscape campus. This laptop is configured as "person.pacbell.net", so when I hit URL w/ hostname (http://public/), it goes to public.pacbell.net. I know these URLs are a bad idea, but people still like to use them, even on my corporate network. If they are inline or in email, I have to copy the URL, create a new window, and hack the URL before surfing. I've created an RFE for this in bug 88217.

*** This bug has been marked as a duplicate of 43429 ***

REOPEN: This is actually a super-set of bug 43429, which only focused on Proxy configs. This RFE covers all Conn: and DNS: related problems with network switching as well.

benc, the other bug was intended to cover all those issues. However, I don't see which network issues there are other than the proxy. Isn't the default domain a thing of the OS? How is it determined? What other issues are there?

Probably also a list of available MailNews servers, as well as changing the default smtp server would go in these things. I think some people might like to associate a default screen-name to the profile (to reflect work or home), but that would be more of a physical location manager feature. I've changed the summary to ~"network profile", because I think that is a better name for what I am getting at.

> Probably also a list of available MailNews servers, as well as changing the > default smtp server would go in these things. I disagree. Users are smart enough not to open an account that is not available on that network. Default SMTP server might be an idea, but not that urgent, because you can assiciate SMTP servers with the identites (->accounts). > I think some people might like to associate a default screen-name to the > profile (to reflect work or home), but that would be more of a physical > location manager feature. huh? What is a screen name? A default screen name? > I've changed the summary to ~"network profile", because I think that is a > better name for what I am getting at. That might be confused weith roaming. Changing back. Again, apart from the

d/Again, apart from the/

*** Bug 139958 has been marked as a duplicate of this bug. ***

*** Bug 152307 has been marked as a duplicate of this bug. ***

moving neeti's futured bugs for triaging.

[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.

*** Bug 200379 has been marked as a duplicate of this bug. ***

-> defaults Changing name back to "network profile" for searchabiility (there was not comment explaining the change, and I'm the reporter). So, I've been giving this more thought on how it should work. The feature should store info in prefs, or RDF. I don't understand RDF very well, but I suppose there would be some portability advantages by having net configs be in a separate file. Assuming prefs is used, I'd like to store the netprofile data in a subtree of network.*, named "network.profile.<profilename>", in a set of prefs that mirror the normal network.* values. The prefs panel would need a menu for adding, deleting, and selecting the netprofile, which would then copy the subtree values over the main values. The first implementation should not support all networking prefs, just those that relate to network-specific configuration information. Later, we could add more user-specific stuff, depending on how it works out (like mailnews and cookie features proposed in bug 217341).

Now that Firefox does network detection and automatically sets the offline mode, users who are running local servers are complaining that they become unavailable when they disconnect from a network. Network profiles sounds like a good solution to this. By default there could be 3 profiles: - Offline (all networking is disabled) - Networkless (allows local connections) - Online (all networking enabled) When autodetection changes the network profile, it would switch between the currectly/last selected profile and the Networkless profile. If The user has manually selected the Offline profile, then auto detection would effectively be ignored. As Comments #1 & #2 allude to, this would also be an excellent way to manage Proxies and multiple network devices. I think that as computing and networking environments become more complex, this kind of feature becomes more important. I'm hesitant to suggest this for Mozilla1.9.x because I'm not sure what is planned or how much work this would be involved. That being said, I would like to mark this wanted for mozilla2 (when that flag becomes available) and, depending on user reactions at the MozillaZine forums, I may recommend this to be nominated for blocking.

I presume with "local servers" you mean local host, not local network? If so, Mozilla should just allow localhost even when offline.

Yeah, I was talking about localhost. Always allowing connections to localhost would be a good temporary solution, but I think that the larger issue of network configuration still needs to be addressed.

Yes, I think they are independent issues. Can you file a new bug about allowing localhost when offline?

This bug is already dependent on Bug 87717.

Is it all about network routing (natively supported by any OS)?

localhost is allowed offline