http proxy support is broken in apprunner




20 years ago
14 years ago


(Reporter: andreas.otte, Assigned: gagan)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment)



20 years ago
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 in WEbshell 8316270
Assertion failure: 0, at mkgeturl.c:3326

or 2. version:

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

sorry no stacktrace for version 1 yet, trying apprunner in gdb gives version 2.


20 years ago
Summary: Proxy support is broken in apprunner → html proxy support is broken in apprunner

Comment 1

20 years ago

Comment 2

20 years ago
finally got a stacktrace of this stuff while running in gdb testing some wallet
stuff and then typing in the location line.


20 years ago
Summary: html proxy support is broken in apprunner → http proxy support is broken in apprunner

Comment 3

20 years ago
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.

Comment 5

20 years ago
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
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)

Comment 7

20 years ago
Necko landing...

Comment 8

20 years ago
paulmac...all platforms?


20 years ago
OS: Linux → All
Hardware: PC → All

Comment 9

20 years ago
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?

Comment 10

20 years ago
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...

Comment 11

20 years ago
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

Comment 12

20 years ago
*** Bug 9096 has been marked as a duplicate of this bug. ***

Comment 13

20 years ago
*** Bug 9096 has been marked as a duplicate of this bug. ***

Comment 14

20 years ago
*** Bug 9807 has been marked as a duplicate of this bug. ***

Comment 15

20 years ago
Changing all Networking Library/Browser bugs to Networking-Core component for

Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do
this in a bulk change.  If this happens, I will fix. ;-)

Comment 16

20 years ago
*** Bug 6540 has been marked as a duplicate of this bug. ***

Comment 17

20 years ago
Gagan, you might work with Matt on this to make sure that the prefs are all
hooked up correctly also.


20 years ago
Target Milestone: M9 → M10

Comment 18

20 years ago
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. ***


20 years ago
Blocks: 8298


20 years ago
Blocks: 5105


20 years ago
Closed: 20 years ago
Resolution: --- → FIXED

Comment 22

20 years ago
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.

Comment 23

20 years ago
Where is prefs50.js now?

Comment 24

20 years ago
It's called prefs.js again.


20 years ago

Comment 25

20 years ago
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#);

Comment 26

20 years ago
What about proxies that require authentication?
A dialog box normally (other browsers) prompts for username/password.


20 years ago
QA Contact: paulmac → mmmr7ckl

Comment 27

20 years ago
* Prefs50.js does not exist, and is now all.js

* Don't forget to change

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


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

Otherwise the proxy settings will not work.


20 years ago

Comment 28

20 years ago
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");
 user_pref("network.proxy.ftp_port", 8088);

It seems that the preference saving code is the culprit here.


20 years ago
Resolution: FIXED → ---

Comment 29

20 years ago
Clearing FIXED resolution due to reopen.

Comment 30

20 years ago
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.

Comment 31

20 years ago
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.


20 years ago
Closed: 20 years ago20 years ago
Resolution: --- → FIXED

Comment 32

20 years ago
there is already a separate bug on proxy auth. 15927. Closing this.

Comment 33

20 years ago
Bulk move of all Networking-Core (to be deleted component) bugs to new
Networking component.

Comment 34

18 years ago

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