It's missing from the UI because of this http://mxr.mozilla.org/mozilla-central/source/browser/components/preferences/connection.js#40 So the core question is why the undefined property? I doubt there's an error on Windows as the implementation is completely different. The linux/unix impl is here: http://mxr.mozilla.org/mozilla-central/source/toolkit/system/unixproxy/nsUnixSystemProxySettings.cpp Windows implementation is here: http://mxr.mozilla.org/mozilla-central/source/toolkit/system/windowsproxy/nsWindowsSystemProxySettings.cpp
I see this too. But neither the lines in connection.js nor nsUnixSystemProxySettings has been changed since February, so it must be something else. cc-ing reed, who touched the connection.js logic last.
Status: UNCONFIRMED → NEW
Ever confirmed: true
A regression range would probably be the most useful thing here.
(In reply to Josh Matthews [:jdm] from comment #3) > A regression range would probably be the most useful thing here. The bug is showing up in ftp://ftp.mozilla.org/pub/firefox/nightly/2012-06-17-mozilla-central-debug/ but not in ftp://ftp.mozilla.org/pub/firefox/nightly/2012-06-16-mozilla-central-debug/.
That should correspond to http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4e3362864fbd&tochange=264f0a7a878c&, but I'm not seeing any culprit stick out at me :/
moving to Firefox, since AFAICT this is a UI issue and not the result of a necko change.
Component: Networking → Preferences
Product: Core → Firefox
This is definitely not only a Firefox issue. I can reproduce the bug on the latest Thunderbird Daily and Seamonkey Nightly as well. And why should that be a UI issue? Getting ReferenceError: reference to undefined property Components.classes['@mozilla.org/system-proxy-settings;1'] does not seem to involve a UI at all IMO.
tracking-firefox16: --- → ?
Component: Preferences → Networking
Product: Firefox → Core
Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/290c7dcdeac3 Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/16 Firefox/16.0a1 ID:20120615225224 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/88d69928e3b1 Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/16 Firefox/16.0a1 ID:20120615230725 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=290c7dcdeac3&tochange=88d69928e3b1 Suspected: Bug 627699
Assignee: nobody → stransky
Caused by http://hg.mozilla.org/mozilla-central/diff/88d69928e3b1/toolkit/library/nsStaticXULComponents.cpp I assume we should just use MOZ_WIDGET_GTK and remove MOZ_ENABLE_GTK2 from toolkit/library/Makefile.in Looks like there's no point even testing for gtk for nsAutoConfigModule.
Created attachment 648203 [details] [diff] [review] replace MOZ_ENABLE_GTK with MOZ_WIDGET_GTK to restore nsUnixProxyModule I checked that nsStaticXULComponents.o now contains nsUnixProxyModule (but haven't tried to pick up any GNOME proxy settings).
Assignee: stransky → karlt
Status: NEW → ASSIGNED
Attachment #648203 - Flags: review?(roc)
Attachment #648203 - Flags: review?(roc) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/77fea247fe32 Try build here (Reftest had GL layers enabled): https://tbpl.mozilla.org/?tree=Try&rev=c91996287d43
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
Comment on attachment 648203 [details] [diff] [review] replace MOZ_ENABLE_GTK with MOZ_WIDGET_GTK to restore nsUnixProxyModule [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 627699 User impact if declined: losing proxy configuration from system settings Testing completed (on m-c, etc.): on m-c Risk to taking this patch (and alternatives if risky): Low risk; this is restoring code that was accidentally removed. String or UUID changes made by this patch: None.
Attachment #648203 - Flags: approval-mozilla-aurora?
Attachment #648203 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
status-firefox16: --- → fixed
You need to log in before you can comment on or make changes to this bug.