8559 - http proxy support is broken in apprunner

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[Andreas Otte]

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.

Comment 1

[Andreas Otte]

Attachment: gdb stacktrace of the incident

Comment 2

[Andreas Otte]

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.

Comment 3

[Paul MacQuiddy]

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.

Comment 4

[Peter Van der Beken]

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

[mcmullen]

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.

Comment 6

[Peter Van der Beken]

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

[Gagan]

Necko landing...

Comment 8

[leger]

paulmac...all platforms?

Comment 9

[Gagan]

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

[Paul MacQuiddy]

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

[James Everingham]

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.

Comment 12

[Paul MacQuiddy]

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

Comment 13

[Paul MacQuiddy]

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

Comment 14

[Paul MacQuiddy]

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

Comment 15

[leger]

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. ;-)

Comment 16

[Gagan]

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

Comment 17

[Paul MacQuiddy]

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

Comment 18

[Gagan]

Proxy support slated for M10.

Comment 19

[Matthew Tuck [:CodeMachine]]

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?

Comment 20

[Hixie (not reading bugmail)]

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).

Comment 21

[Matthew Tuck [:CodeMachine]]

*** Bug 13468 has been marked as a duplicate of this bug. ***

Comment 22

[Gagan]

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

[edburns]

Where is prefs50.js now?

Comment 24

[selmer (gone)]

It's called prefs.js again.

Comment 25

[Paul MacQuiddy]

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

[Glenn McGrath]

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

Comment 27

[Christopher Lam]

* 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.

Comment 28

[Eric Gouriou]

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.

Comment 29

[leger]

Clearing FIXED resolution due to reopen.

Comment 30

[matt]

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

[Russell Loewen]

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.

Comment 32

[Gagan]

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

Comment 33

[leger]

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

Comment 34

[benc]

VERIFIED:

HTTP proxy has been working for some time, including mozilla 0.9 on all 
platforms.