Does YaST set the proxy settings in gconf? If not, how should I get them?

YaST basically sets the environment variables $http_proxy and $https_proxy.
This discussion is very old and at any time there was the plan to extend the gconf database to fall back to these variables if nothing else is set.
The upstream feature request is 
https://bugzilla.mozilla.org/show_bug.cgi?id=66057

The gnome-settings-daemon should keep the GNOME proxy setting in sync with the gconf one as of NLD9 SP2.  Federico did this work.

Our Bangalore team wrote the patches for Firefox to read the proxy settings from GConf.  Don't we include those in our Firefox package for Suse 10?

Hummm, it even looks like we don't include the proxy patch in control-center2 in Suse 10.  We included it in Suse 9.3.

We will use the gconf settings for all kinds of things if use_system_prefs is enabled. But we don't want to enable that by default.

I think we might fix upstream bug 66057 by having the existing "auto-detect proxy configuration" option (which currently uses WPAD, i.e., looks for wpad.mydomain) check HTTP_PROXY/FTP_PROXY first. Then we could make auto-detect proxy configuration the default setting. As far as I can tell it doesn't hurt if there is no WPAD server present.

Lets give this a try then.

JP, do we want this for CODE10? Robert, I don't know if I have enough time until feature freeze. Basically it's just getenv and check if they contain values and use them?

I don´t understand why you wnat to change something inside firefox. It´s just the default setting which needs to be changed IMHO, and firefox will read the settings from the environment vars (at leas on my systems it does).

It's pretty important for a running Firefox process to pick up changes in the proxy settings through GConf.  Otherwise you would have to restart it.

In a GNOME session, the GConf settings are the most important ones.

Yes this would be the best solution, but if SuSE should be that perfect I could submit another 30 bug reports (this is nothing against SuSE, it´s still the best distro around).

Hey, we aim for perfection.  Do submit those reports :)

to comment #9: Firefox doesn't use the $*_proxy variables. What you mean are the gconf settings.

to comment #10: yes, in GNOME sessions it would be OK to use the system prefs (gconf settings). AFAIK Robert's patch can sync the Firefox proxy settings with gconf's. Maybe we should detect a GNOME session and activate system prefs? Robert, do you think it's safe to switch it on?

This bugreport is mainly about the whole system and the only setting which should be honored by every application are the env variables $http_proxy and $ftp_proxy ( if not superseded by another more special setting). This is what this bug is about IMHO.

I'm going to fix this as soon as I figure out what should be implemented.

If picking up dynamic changes is important (and I agree that it probably is) then the environment variables are useless, and gconf is the way to go. However, turning on the full gconf system-prefs facility is not the right way to go. It's too invasive and risky where it's not absolutely necessary.

How about this. My new system-prefs code contains a list of the preferences that should be mapped. I can generalize it to support multiple lists, with the actual list selected at startup time. At startup we'll do the following:
-- If gconf is not installed then the gconf system prefs module won't load and no gconf prefs will be mapped.
-- If gconf is installed the gconf system prefs module will load. Then we check the config.use_system_prefs pref. If it's true, then we map all supported gconf prefs.
-- Otherwise we check DESKTOP_SESSION. If it's 'gnome', then we map the gconf proxy settings only.
-- Otherwise we map nothing.

How does that sound? There is one more question to decide: should the user be able to change the proxy via the Firefox preferences UI? If so, should those changes be written back to gconf?

This sounds good but then we have no support for the env vars again.
And I don't think that dynamic updates have to occur in a running application (for environment variables). No other application is doing this AFAIK. The variables are still the only common denominator for all applications and desktops. We can set it with YaST and online-update is using it as well.

Your suggestion is still very interesting but you know that feature freeze is near?
To your question about the Firefox UI: The default is greying it out if taken from gconf but then we have the problem that the user doesn't know why it's locked.
I would also not force the user to use the gconf proxies. He might want to use different proxy settings for different applications.
The biggest problem here is user experience and not the implementation :-(

What I just suggested is a very small amount of work on top of the existing lockdown patches. Probably less work than using HTTP_PROXY.

But okay, how about this combination of my previous suggestions:
-- Make "auto-detect proxy configuration", which currently uses WPAD, use gconf instead if DESKTOP_SESSION is "gnome". We will assume that if the user/administrator wants WPAD then they will point gconf's /system/proxy/autoconfig_url at http://wpad/wpad.dat (which is all WPAD does).
-- When DESKTOP_SESSION is not "gnome", make "auto-detect proxy configuration" check *_PROXY env. vars first before checking WPAD.

This work is now right?

yes, it will be in beta1.

I tested it in beta6 and while it works in KDE it doesn´t work in GNOME.

Could you please explain what doesn't work in GNOME?

Firefox is set to "auto-detect proxy settings".
This does work in KDE but doesn´t work in GNOME.
In GNOME I can´t access any websites using firefox.

Then it's a GNOME problem if it is one at all.
What are your GNOME proxy settings in gnome-control-center?

I didn´t change any settings, it´s set to "use system proxy settings".
Another thing which I really don´t understand (after reading the whole discussion above) is why you use gconf. Why don´t you just use the environment variables no matter which desktop is used. This is what is done by wget&co and this works always.
You use gconf under gnome, so why don´t you use kdenetwork under kde. It also has an option to set the proxy in the kde control center for all kde apps. So either it´s "complete" support for both kde and gnome or the env vars which are always set and desktop-independant IMHO.

Since gconf integration is already available in Firefox and the system variables are
1. basically a system-default set by the administrator
2. to unix-like to know for the beginner
it makes sense to use the gconf settings when running in Gnome environment.
But we fallback to environment variables which is a good thing.
The reason why there is no support for KDE is simply because noone provided a patch to use it.

I think the current implementation is the best trade-off for now.

I just have tested again with beta8 and I can confirm that we have a problem.
Firefox in KDE gets the environment variables and is using them without problems.
Firefox in Gnome doesn't work. As epiphany works correctly under Gnome there might be an issue with our Firefox patch and it doesn't get the gconf settings correctly.
That's a bug we have to fix as soon as possible. Robert, would you please have a look at it (in addition to myself)?

If I look in gconf settings if system_values are used I see the proxy settings almost correctly. The "secure_host" setting is empty but https_proxy is set correctly in the environment. So this might also be a gconf bug.

(opened another bug for the secure_host thing)

It turned out that this is a Firefox specific problem.
If I set gconf settings they are also not used or wrongly used and Firefox doesn't load anything.

Does the patch that we had in Suse 9.3 work for our most recent Firefox package?  It certainly worked back then.

The description of how proxies work in Suse+GNOME is here: https://wiki.innerweb.novell.com/index.php/NLD_GNOME_Proxy_Configuration

The current patch to get the gconf proxies is completely different to what we used in Firefox 1.0.x when use_system_settings was used there.
I think I understand how proxy settings work.
If Firefox is not running under Gnome it uses the environment variables directly which definitely works. But getting the proxy settings through gconf doesn't work currently.

Created attachment 73857 [details]
fix

Here's an updated system-proxies.patch. I installed squid and verified that with this patch I can access my proxy on localhost when I set that from gconf.

regarding comment #28, we still have that code ... well, an updated version of it. But it's only active when config.use_system_prefs is enabled. Its effect is to force synchronization of Mozilla proxy settings with gconf (so any changes through Firefox UI will propagate back to gconf, mandatory gconf settings disable the Firefox UI, etc).

This bug is about making it possible, as an option, for Firefox to read the gconf or other system settings, whether or not use_system_prefs is enabled (use_system_prefs is disabled for most users).

Thanks Robert. The patch works for me.

Firefox configuration is working much better now, but I can not force Firefox to read the WPAD information provided by DHCP. 

I suggest to add another option to Firefox, something like "Use System settings"; then the functionallity of WPAD would work having "auto-detect the proxy settings" set, and "Use system settings" would read the current GNOME/KDE settings. This feature would even be usefull to have in Windows...

We explicitly decided not to add another option, but it was discussed.  WPAD settings should be preferred however, that was part of this patch.

(In reply to comment #33)
> Firefox configuration is working much better now, but I can not force Firefox
> to read the WPAD information provided by DHCP.

You can choose "use system settings" and then configure WPAD via gconf. You set /system/proxy/mode to "auto" and /system/proxy/autoconfig_url to http://wpad/wpad.dat. You need to do this anyway to make sure that GNOME applications work.

> I suggest to add another option to Firefox, something like "Use System
> settings"; then the functionallity of WPAD would work having "auto-detect the
> proxy settings" set, and "Use system settings" would read the current
> GNOME/KDE settings. This feature would even be usefull to have in Windows...

Actually, in the upstream version of this patch I am adding a new preference for this, due to feedback (and there's a guy working on a Mac implementation, but no Windows yet). We could apply the upstream version here too, if we want to.

(In reply to comment #34)
> We explicitly decided not to add another option, but it was discussed.  WPAD
> settings should be preferred however, that was part of this patch.

Actually this patch was designed to fall back to WPAD when environment variables and gconf are not available. In GNOME setups gconf is always available so WPAD will not be used unless it is configured in gconf.

In my opinion, it makes configuration confusing, because firefox behaves different in different environments.

In a network at one of my customers we are using WPAD to use different proxies for different target addresses. The only way to do that is to use complex scripts (proxy.pac);
up to now the configuration was very simple, because the users could simply use Firefox's standard setting "auto-detect the proxy settings". Now it seems necessary to set the proxy setting individually for each users in the private gnome setup.

That is true. I had assumed people like that would have the correct gconf settings too, so that their GNOME apps can fetch with HTTP, but I guess not. Anyway we've decided to take the upstream version of this patch, which uses a new preference, which I will attach here for Wolfgang soon.

I've checked the proposed patch.
The problem with this is, that we would have to add an option in the UI which is not available in upstream Firefox. Therefore no translations are available for this option and the way how the localization works in mozilla stuff will break the UI almost completely.
So if we really want to change it that way, someone would have to maintain 31 language packs internally.

I think those changes should be suggested to the Firefox project, to have this feature for every Firefox releases (as mentioned before, it would also be nice to have this facility in the MS Windows environment and on Apple computers).

When you (from Novell/SuSE) can propose this patch and donate it to the Mozilla project, I could imagine, that they will include it to the sources...

Thank you for the great work and sorry for the work my posting caused ;-)
Johannes

The patch we are talking about is already half-way in the Firefox original code.
But it can be added at the earliest with Firefox 2. But we have to ship 1.5.x soon ;-)

This not critical for 10.1.

Wolfgang, JP and I decided to try reusing an existing string.

From here:
http://lxr.mozilla.org/mozilla/source/browser/components/preferences/fonts.xul#45,
copy
<!DOCTYPE prefwindow SYSTEM "chrome://browser/locale/preferences/fonts.dtd" >
into browser/components/preferences/connection.xul.

Then you can set the preference string to &resolution.system.label;
In English that string is "System setting", which works OK in this context. I don't know if it still makes sense in other locales though.

Hey, if that doesn't work we can write some JS code to ask Babelfish to translate "Use system settings" into the desired language :-).

package submitted with proposed change

Hello!

The released version works great. Well done! I think, the bug can be closed.