proxy settings with ports specified are not imported properly




14 years ago
14 years ago


(Reporter: Hussam Al-Tayeb, Assigned: Ben Goodger (use ben at mozilla dot org for email))


Windows XP
Bug Flags:
blocking0.9 +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: fixed-aviary1.0)


(1 attachment)



14 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier:

when migrating from IE6 to firefox0.8+, the proxy settings are not corectly 
migrated. if my proxy is and port is 8080,
firefox will migrate the following : proxy is and port is 8080

Reproducible: Always
Steps to Reproduce:
1.Set IE as default browser and install firefox. 
2.Open a clean new profile and firefox will migrate your IE settings.
3.Open the options dialog in firefox and go to the connection settings.

Actual Results:  
instead of proxy is and port is 8080, firefox says proxy is and port is 8080

Expected Results:  
connection settings in firefox should say:
proxy is and port is 8080


14 years ago
Flags: blocking0.9?

Comment 1

14 years ago
Same problem witnessed here at work.  I'll vote for the bug.
We're actually dying here, although I can't figure out why myself:

This affects migration from any browser, not just IE.  This might even be
all/all, but I haven't played with migration from other platforms yet.

Tested on IE 6 and Opera 7.5 migrators.
Severity: normal → major
QA Contact: mconnor
Summary: proxy settings from IE6 are not migrated correctly → proxy settings with ports specified are not imported properly
does this actually prevent the proxy from functioning or is it a cosmetic issue?

Comment 4

14 years ago
(In reply to comment #3)
> does this actually prevent the proxy from functioning or is it a cosmetic issue?

Definitely, it will prevent the proxy from functioning. You will have to set the
proxy yourself manually. 

this is definitely a blocker then.  (And probably all/all, but I still haven't
tested that yet).
Flags: blocking0.9? → blocking0.9+
be aware this is a problem in Trunk and Branch (tried both)!

Comment 7

14 years ago
*** Bug 243929 has been marked as a duplicate of this bug. ***
Created attachment 149132 [details] [diff] [review]
use cautostrings instead of dependentcstrings

We do need to copy into nsCAutoStrings here because we need null termination.
Otherwise when we feed the result of Substring() into nsDependentCString's ctor
it asserts because the length it thinks its receiving (mLength) is not the same
length as the buffer (the full proxy segment).
This bug was introduced by 237190. The copy doesn't bother me so much since this
is not a performance critical operation. Fixed branch and trunk.
Last Resolved: 14 years ago
Resolution: --- → FIXED
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040524
Firefox/0.8.0+ (build after checkin)

propose REOPENED
i/o displaying http://proxyname/:portnumber (which was wrong)
it now displays http://proxyname/ which does not work either.

only proxyname without http:// and without ending / does work
er, where'd the trailing / come from?

all this code does is take and separate it to
and 1080, if the original is and it should parse that
trailing slash out, that's a separate bug (although the question is how did that
work in the first place in the other browser?)
I allways had to remove the http:// part (also in 0.7 and 0.8)
additiional comment
I checked the settings here and the sysop had the proxyserver defined as 
http://servername/ (in IE).
IE doesn't seem to care , like in so many cases.
I don't know if FF shouldn't strip the http:// off if it's malconfigured in IE ?
But this bug can remain fixed.

If needed I can open a new bug for it, but only if it won't get a WONTFIX 
advice please.
if IE allows it, but we don't, then we do need to strip the hostname out of the
string.  Please file said bug and cc me on it :)


14 years ago
Whiteboard: fixed-aviary1.0
*** Bug 252405 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.