Closed Bug 219456 Opened 21 years ago Closed 21 years ago

proxy browsing broken on todays cvs 20030917

Categories

(Core :: Networking, defect, P1)

Product:
Core
Component:
Networking
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.6alpha

People

(Reporter: Mitch, Assigned: darin.moz)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

v1.1 patch
1.39 KB, patch
dougt
: review+
alecf
: superreview+
Details | Diff | Splinter Review 
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.
Flags: blocking1.5?
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?
Keywords: regression
> 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
OS: SunOS → All
Hardware: Sun → All
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.
Flags: blocking1.5?
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.
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla1.6alpha
*** 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.
Flags: blocking1.5?
ok, so the target milestone should be changed to 1.5final.
Flags: blocking1.5? → blocking1.5+
Flags: blocking1.5+ → blocking1.5?
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.
Flags: blocking1.5?
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 (!)
Attached patch v1 patch (obsolete) — — Splinter Review 
simple patch.  pref parser changes unintentionally dropped the all-to-critical
line which enables pref change observers ;-)
Attached patch v1.1 patch — — Splinter Review 
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.
Attachment #131914 - Attachment is obsolete: true
Attachment #131915 - Flags: superreview?(alecf)
Attachment #131915 - Flags: review?(dougt)
Attachment #131915 - Flags: review?(dougt) → review+
Comment on attachment 131915 [details] [diff] [review]
v1.1 patch

yikes :)
sr=alecf
Attachment #131915 - Flags: superreview?(alecf) → superreview+
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
*** 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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: