Closed Bug 8559 Opened 25 years ago Closed 25 years ago

http proxy support is broken in apprunner

Categories

(Core :: Networking, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: andreas.otte, Assigned: gagan)

References

Details

Attachments

(1 file)

Lately (the last three or four days) proxy support is broken in apprunner. The
prefs in prefs50.js are igored, I´m getting messages like this:

1. version:

Doing Startup...
Creating browser app core
BrowserAppCore has been created.
Adding app core to AppCoreManager in the base initialization.
Setting content window
Loading  url http://www.mozillazine.org/ in WEbshell 8316270
Assertion failure: 0, at mkgeturl.c:3326
Aborted


or 2. version:

Loading  url http://www.mozillazine.org/ in WEbshell 8166fc8
nsDocumentBindInfo::OnStopBinding: Load of URL 'http://www.mozillazine.org/'
failed.  Error code: 1
Error loading URL http://www.mozillazine.org/
Document: Done (0.614 secs)

sorry no stacktrace for version 1 yet, trying apprunner in gdb gives version 2.
Summary: Proxy support is broken in apprunner → html proxy support is broken in apprunner
finally got a stacktrace of this stuff while running in gdb testing some wallet
stuff and then typing www.mozilla.org in the location line.
Summary: html proxy support is broken in apprunner → http proxy support is broken in apprunner
cc'ing mcmullen to see if he might know why some prefs are being ignored now.
The following prefs

user_pref("network.proxy.http", "chainsaw");
user_pref("network.proxy.http_port", 8288);
user_pref("network.proxy.type", 1);

used to enable proxy to work in apprunner, now they are ignored.
Apparently the necessary callback in netlib (NET_PrefChangedFunc) is not called
when the network preference change while loading the prefs50.js file. You can
force mozilla to use the proxy info by changing the proxy type in the preference
dialog, OKing, then changing it back to the right type (after which
NET_PrefChangedFunc is called). The next time you load mozilla, it will fail
again, though.
At what point does the callback get installed? As far as I understand the design,
nobody should rely on a callback being called during pref initialization
(including reading of prefs50.js). The userprefs should be initialized before
anybody tries to install callbacks. So I do not think this is a prefs bug. I
think it is a netlib bug.

Curious that this used to work until recently. I think the problem is that we
changed the order of loading. It used to be:

default prefs
user prefs
profile wizard

Now it's

default prefs
profile wizard
user prefs.

Now, if the profile wizard comes up, then unfortunately netlib gets in the
picture. I think this must be the problem, right? So this problem should not
occur if you relaunch with a single profile, so that no wizard appears at this
stage.
It happens with one profile (no profile wizard).
Netlib is loaded at line 507 of file nsApprunner.c in function main (rv =
NS_NewURL(&url, urlstr)). I think that that is the first time it gets called.
ReadUSerPrefs only happens at line 650 of that file. When Netlib initializes, it
initializes its prefs and the callback (NET_PrefChangedFunc) is called. However,
when ReadUserPrefs is later called, and proxy values are (should be) read in,
the callback isn't called, leaving the prefs at their default values.

(BTW This is on mac, so it's probably cross-platform)
Necko landing...
paulmac...all platforms?
OS: Linux → All
Hardware: PC → All
As it turns out, this bug is really two things- first the option to set proxies
in Netlib (necko henceforth) and then the broken(?) link between preferences and
their callbacks. The proxy support in Necko should be getting added as soon as
Necko lands completely. But we may have to split this bug for the other half. Am
not marking this M9 for now till the other bug is created... Paul, who owns
prefs now?
Gagan, it might be 3 bugs :-) Matt would be the one to put in the front-end UI
for this, and he already has a bug 6540 on this. As far as who owns the
callbacks, I'm not sure right now. I actually thinks the netlib part of it
is working right now, but we'll keep this one open as the back-end bug to see
how necko does...
I'm moving this to target M9, Necko will be enabled somewhere during late M8 or
early M9.  We will need to get on this and it cannot be postponed past the M9
milestone.
*** Bug 9096 has been marked as a duplicate of this bug. ***
*** Bug 9096 has been marked as a duplicate of this bug. ***
*** Bug 9807 has been marked as a duplicate of this bug. ***
Changing all Networking Library/Browser bugs to Networking-Core component for
Browser.

Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do
this in a bulk change.  If this happens, I will fix. ;-)
*** Bug 6540 has been marked as a duplicate of this bug. ***
Gagan, you might work with Matt on this to make sure that the prefs are all
hooked up correctly also.
Target Milestone: M9 → M10
Proxy support slated for M10.
Is this going to happen early in M10?  I've been waiting for a while already,
but it'd be nice to know when I can start testing properly again ...  Is it
blocked on another feature being implemented?
The following bugs also address proxy issues:
   bug 6540 (prefs front end).
   bug 7398 (where to store the prefs).
   bug 10276 (autoconfig and necko proxy support).
Blocks: 7529
*** Bug 13468 has been marked as a duplicate of this bug. ***
Blocks: 8298
Blocks: 5105
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Thats one long CC list! Looks like you guys really want proxies. OK checked in.
(No autoconfig as yet) but basic support is there now.
Where is prefs50.js now?
It's called prefs.js again.
Status: RESOLVED → VERIFIED
this is working now, on all platforms, just add the prefs below to your mozilla
prefs.js file. Note the UI is not quite functional so this must be done manually
for now. Substitute servername for your server and port# for your port. Same
prefs as 4.x, BTW.
user_pref("network.proxy.http", "servername");
user_pref("network.proxy.http_port", port#);
What about proxies that require authentication?
A dialog box normally (other browsers) prompts for username/password.
QA Contact: paulmac → mmmr7ckl
* Prefs50.js does not exist, and is now all.js

* Don't forget to change

pref("network.proxy.type",                  0);

to

pref("network.proxy.type",                  1);

Otherwise the proxy settings will not work.
Status: VERIFIED → REOPENED
On M11 win32 (tested on NT), the proxy configuration is broken again.
I fixed my pref.js file manually by changing odd-looking entries like:
 user_pref("string:network.proxy.ftp_port", "8088");
to
 user_pref("network.proxy.ftp_port", 8088);

It seems that the preference saving code is the culprit here.
Resolution: FIXED → ---
Clearing FIXED resolution due to reopen.
Which build are you using.
This got fixed last week and i just tried it
again and it is working correctly.
Can you pull down a new build and verify it?
You need to restart the navigator for it to take effect.
I too am testing the M11 build on Win32 NT, and even with my edits to the
preferences document my proxy is failing. I get the standard Proxy
Authorization failed message from my proxy, but M11 does not provide me with a
proxy login dialog.
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
there is already a separate bug on proxy auth. 15927. Closing this.
Bulk move of all Networking-Core (to be deleted component) bugs to new
Networking component.
VERIFIED:

HTTP proxy has been working for some time, including mozilla 0.9 on all 
platforms.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.