User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.5b) Gecko/20030916 Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.5b) Gecko/20030916 Using a proxy for web browsing seems to be broken in todays cvs 20030917 build. Switching to yesterdays build with no other user setting change and it works fine again. I can see no relevant change in CVS checking yesterday. Reproducible: Always Steps to Reproduce: 1. Enable proxy settings 2. Try to go to a web site 3. Actual Results: Error dialog saying "host xxxx cound not be found" Expected Results: obvious

is your proxy an ip address or a hostname? (yes it's a strange question)

It's a hostname - and can be resolved.

Proxy browsing is broken in 20030917 nightly build using proxy hostname, ip, or autoconfig script. I can still browse local webservers that don't need a proxy even though they are not in my "no proxy for:" list. I can browse all websites using the proxy in IE 6SP1 and phoenix 0.6.1. I am using Win2000 SP4.

hardware -> All OS -> All

I have this bug too. i have windows xpsp1. In the 20030917 builds of firebird and mozilla, both browzers refuse to use my proxy settings.

Im not using any proxy but I cant browse at all, even things on my localhost (such as cups) using cvs 20030917 build, with clean .phoenix. No error, it just wont do it. My net its correctly set because i can browse with Konqueror. Using Gentoo, mozilla-firebird-cvs ebuild.

How old is this regression? Was it present in yesterday's builds? Michael, you nominated this bug for "blocking1.5". Does this bug affect the 1.5 branch?

> How old is this regression? Was it present in yesterday's builds? See my initial comment: Using a proxy for web browsing seems to be broken in todays cvs 20030917 build. Switching to yesterdays build with no other user setting change and it works fine again.

no it worked fine in yesterdays build, starting on 17th build, the browser refuses to use the set proxy settings

If I launch the previous nightly build, and an instance of the latest build, this latter connects (hope this can help in localising where is the bug).

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

Is there perhaps something curious in the parsing requirements for the proxy prefs -- *or the prefs just before the proxy prefs* -- that confuses the new hand-written prefs parser?

This showed up with a 20030916 build of Firebird for me. I've backdated to a 20030912 build, which is working perfectly.

To clarify: my proxy is a SOCKS5 proxy, and I connect by IP address.

the bug appears when using http and socks proxy

> the bug appears when using http and socks proxy That is not true. I'm not using SOCKS at all.

The official Firebird 09/16 build works fine, the 09/17 build is broken: It connects directly to the internet without using the proxy. I use Webwasher, an ad-blocker, as a local proxy. With the 09/17 build I see all the ads I normally don't see.

Sorry this should not block 1.5branch my mistake

is your browser set for 1.0 or 1.1 proxies? I believe 1.1 is the default.

network.http.proxy.version is set to 1.1, which has to be the default as it's not marked bold in about:config. Setting to 1.0 doesn't help.

mconner said this might be from the big DNS rewrite. That would be Darin's doing, afiak.

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

I use Proxy Auto Config to call a no-ads.pac file (see http://www.schooner.com/~loverso/no-ads/) hosted on the same machine (http://localhost/no-ads.pac). I too have been seeing ads that should be blocked, since downloading the 9-17 build.

i've 127.0.0.1:4001 given as proxy and firebird also ignores it

Re comment 7 and others, I downloaded the http://ftp.mozilla.org/pub/firebird/nightly/2003-09-16-08-trunk/MozillaFirebird-win32.zip from squarefree and it did not work with my proxy settings (did not show up username/password dialogue). I have used previous builds without problems, but now I have returned to 0.6.1 - and it works.

Re comment #21. It does not really make sense that this has to do with the DNS rewrite as taht code has been in place for all Firebird nightlies sine 0912 which did not exhibit this problem. Is it possible this has to do with the new lightweight prefs.js parser? Like is the problem that the prefs file is not being correclty parsed and that is causing the proxy issue?

How would we verify the prefs.js parser? Are you saying it wouldn't be listed in about:config?

I really don;t know. I was sjust looking at all the checkins between the last none good version and first known bad version and this was the only thing that seemed to stick out.

about:config looks the same on both the old (working) build and a recent build. I should point out that the 20030916 breakage that I mentioned was with Daihard's (http://pryan.org/firebird/daihard/) build, not with the official Firebird (although it looks like the official Firebird and Moz builds have the same problem).

I also observed this problem with the builds of both, Mozilla and Firebird, that I downloaded today.

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

Re "Comment #30" That's true. it's been broken in both mozilla and firebird since the 17th.

If target milestone is 1.6a, is there still chance of this being fixed before 1.6a?

This bug really ought to be fixed for 1.5 final; requesting block.

ok, so the target milestone should be changed to 1.5final.

Has anyone actually verified that the bug exists on the 1.5 branch? There have been no direct reports of it here.

No reports other than the original one, you mean. But to confirm, I see this problem with 1.5RC1-Win2K.

Mitch's original report was not against the 1.5 branch. But yours clearly is; thanks.

Re comment #37. Well, I am running the Official win32 1.5 RC1 (build ID Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030916). Proxies work just fine in this release. The proof? I was able to post this.

> Mitch's original report was not against the 1.5 branch. > But yours clearly is; thanks. Hmm. Perhaps I am mistaken, then -- I assumed from the user agent string posted in the original response, showing 1.5b-0916, that he was reporting from the 1.5 branch. I have been assuming my build was 1.5RC1 because the day I downloaded it, the RC1 release was announced. However, I didn't specifically look for 1.5RC1, and just got the latest seamonkey that day: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030917 I further assumed this was not a trunk build because it does not contain the changes checked in on 9/16 for bug 36492, which was the reason I'd gotten this build in the first place. If it helps to identify this build further, it is exhibiting the "broken about: page" problem. If I've screwed up, my apologies -- but if the version number isn't tweaked in the trunk after a branch, I don't see how we're supposed to keep this stuff straight.

I had brought up this topic of users being confused in the Firebird Builds discussion but kind of got nowhere. I think at some point a new method of dealing with nightlies after the trunk is frozen for release is needed as the current method is just too confusing becuase no one knows what they are running. Bascically the situation is that the 1.5 branch was cut on the afternnon of September 10th. So the September 11th and later nightlies are all built off the 1.6a trunk regardless of what the build ID says. The only builds still being made off the 1.5 trunk are Mozilla 1.5 relesase candidates, Mozilla Firebird release candidates and Mozilla Thunderbird 0.3 nightlies (which come out more or less weekly). The automated Mozilla and Mozilla Firebird nightlies were being built off the 1.6a trunk but there have not been any of those for the last couple of days either. From looking at the checkins it appears that the fix for bug 36492 was not checked in until 9/17 and would not have shown up until the 9/18 nightly. The release candidate build for Mozilla is located at: http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.5rc1/

As with many other users, I'm kinda stuck with an old build because of this. When is the proxy bug expected to be fixed? Also, will they release the firebird 0.7 even if it doesn't get fixed in time? Hope not!

Also, I noticed that since release candidate build for Mozilla 1.5 was built on the 16th (before 17) it does not have this bug.

No problem with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030919 Firebird/0.7, which is a 1.5 branch build. So Mozilla 1.5/Firebird 0.7 won't be affected. Clearing the blocking1.5? flag.

yes but I think it still exists in http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-installer-sea.exe

Please stop the discussions in this bug. yes, the bug is in the trunk but not in the branch. The problem is known and the developer should reproduce this very easy. That means = no additional comments This is now Forum, it's a bug databse for the developers (!)

simple patch. pref parser changes unintentionally dropped the all-to-critical line which enables pref change observers ;-)

better patch. this version does away with the assertion and is more consistent with the way gCallbacksEnabled was "set" in the previous version of prefapi.cpp.

Comment on attachment 131915 [details] [diff] [review] v1.1 patch yikes :) sr=alecf

fixed-on-trunk

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

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

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

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

Verified as fixed in 9/23 optimized build.

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

Verified fixed: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20030923