GNOME Bugzilla – Bug 659215
GNOME Control Center doesn't fill out all required proxy settings in GSettings
Last modified: 2012-10-19 15:11:06 UTC
In working on adapting OpenJDK to use GSettings rather than gconf (https://bugzilla.redhat.com/show_bug.cgi?id=735336), I discovered that the GNOME control center proxy settings do not allow a number of important settings to be changed from their default values. Although it's understandable that the new UI may not yet allow more advanced options like authentication and ignored hosts to be set, the lack of being able to enable the http proxy or turn off 'use-same-proxy' make the created settings largely unusable in the majority of cases (e.g. where values are entered for multiple protocols). The schema used by GSettings has defaults for these values: (from /usr/share/glib-2.0/schemas/org.gnome.system.proxy.gschema.xml) <key type="b" name="use-same-proxy"> <default>true</default> <summary>Use same proxy for all protocols</summary> <description>Whether to use the same proxy for all protocols or not.</description> </key> <key type="b" name="enabled"> <default>false</default> <summary>Use HTTP proxy</summary> <description>Enables the proxy settings when accessing HTTP over the Internet.</description> </key> So by default the HTTP proxy is disabled and the same proxy is used for all protocols. In the Java code at least, the existing assumption is that the HTTP proxy is used as the template if use-same-proxy is enabled. As that proxy is disabled, we end up with no proxy being configured, regardless of the fact that the user may have entered a number of proxies for HTTP, HTTPS, FTP and SOCKS in the dialog. The dialog should have an option to toggle 'use-same-proxy'. For the HTTP proxy, either it should be able to enabled or the control center should just enable it if the user sets a value for its host and port.
From the GSettings schema: <key name="use-same-proxy" type="b"> <default>true</default> <_summary>Unused; ignore</_summary> <_description> This key is not used, and should not be read or modified. </_description> </key> </schema> And: <key name="enabled" type="b"> <default>false</default> <_summary>Unused; ignore</_summary> <_description> This key is not used; HTTP proxying is enabled when the host key is non-empty and the port is non-0. </_description> </key> So the way that Java is reading those keys is incorrect. Feel free to reopen if I misunderstood the problem, but the documentation for those keys points to a problem with OpenJDK.
Well, yes, it sounds like you've changed the schema, rather than the control center tool, in the thirteen months it's taken to even respond to this bug... I'll have to find time to look at this again to see if the data/tool are now usable.
(In reply to comment #2) > Well, yes, it sounds like you've changed the schema, rather than the control > center tool, in the thirteen months it's taken to even respond to this bug... It was changed more than 2 weeks before your bug was filed: http://git.gnome.org/browse/gsettings-desktop-schemas/commit/schemas/org.gnome.system.proxy.gschema.xml.in.in?id=6cfbb00ac09e586a819181e7e39270569bb10a5a > I'll have to find time to look at this again to see if the data/tool are now > usable.
In a release? This is a bug against a release. We can't work against random git commits. The version being tested with OpenJDK had this issue at the time. Hence the bug.
(In reply to comment #4) > In a release? This is a bug against a release. We can't work against random > git commits. The version being tested with OpenJDK had this issue at the time. > Hence the bug. It was fixed in the stable GNOME 3.2, which got released 10 days after you filed that bug, and in the development version of gsettings-desktop-schemas (3.3.91) 10 days before you filed the bug. I'm sorry it took so long to get to your bug, but there's only limited man-hours, and we can't process every single bug the day it comes in.
Sure, same here, but over a year seems a pretty long time. I don't see how it being released 10 days or 10 weeks *after* I file the bug makes any difference. I don't have a crystal ball to envisage it being fixed by the time 3.2 actually appears in distros. As I say, I'm not sure whether the bug is fixed or not. I need to investigate it all afresh because I can't remember the issues this long after filing the bug. Only then can I determine whether GNOME or OpenJDK or both needs fixing.
(In reply to comment #6) > Sure, same here, but over a year seems a pretty long time. I'm not responsible for the Network panel, but as the person responsible for it is on parental leave, and we completely redesigned the Network panel this development cycle, I triaged the old bugs. If that bug had been in the correct place (gsettings-desktop-schemas), it would have got looked at earlier. > I don't see how it being released 10 days or 10 weeks *after* I file the bug > makes any difference. I don't have a crystal ball to envisage it being fixed > by the time 3.2 actually appears in distros. > > As I say, I'm not sure whether the bug is fixed or not. I need to investigate > it all afresh because I can't remember the issues this long after filing the > bug. Only then can I determine whether GNOME or OpenJDK or both needs fixing. You can reopen this bug if there's actually something to fix in GNOME.
It's in the right place. It's not a bug against the schema, but that the control panel wasn't reflecting the schema.