User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) Build Identifier: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2004-04-21-09-trunk/ when migrating from IE6 to firefox0.8+, the proxy settings are not corectly migrated. if my proxy is 192.168.68.1 and port is 8080, firefox will migrate the following : proxy is 188.8.131.52:8080 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 192.168.68.1 and port is 8080, firefox says proxy is 192.168.68.1:8080 and port is 8080 Expected Results: connection settings in firefox should say: proxy is 192.168.68.1 and port is 8080
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: http://lxr.mozilla.org/mozilla/source/browser/components/migration/src/nsBrowserProfileMigratorUtils.cpp#48 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?
(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)!
*** 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.
Status: NEW → RESOLVED
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 http://foo.bar:1080 and separate it to http://foo.bar and 1080, if the original is http://foo.bar/:1080 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 offcourse. 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 :)
*** 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.