215457 - PAC: Autoproxy does not work first time browser is started

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[jhp (no longer active)]

This is from a customer report: If you enable autoproxy in all.js (such that a
new install will have it automatically enabled), then you will not be able to
connect to the network the first time the browser is run.

Steps to recreate:
1) On a never-run install of Mozilla, change all.js accordinly:
  pref("network.proxy.autoconfig_url",        "file:///c:/proxy.pac");
  pref("network.proxy.type",                  2);
2) Start Mozilla and create a new profile.
3) Try to view a page on the network.

This will only fail when the browser does component registration (usually the
first time the browser is installed).  So another way to recreate this is to
make the changes in all.js and delete components/*.dat from an existing build.

Using a debug build, I get the following assertion:
  ASSERTION: Failed to get UI EventQueue, nsProtocolProxyService.cpp
It seems that when the autoproxy component in registered, it initializes itself.
 Noticing that there is a PAC file specified, it tries to do the necessary
steps;  specifically, it tried to get the UI EventQueue, but this is not created
until _after_ component registration.

Comment 1

[jhp (no longer active)]

Attachment: patch

This patch was suggested by Dougt.  It moves the creation of the EventQueue to
right before the component registration.

Comment 2

[Darin Fisher]

Comment on attachment 129383 [details] [diff] [review]
patch

wow!  i just discovered the same exact patch and sent it to you in an email! 
r=darin :-)

Comment 3

[Doug Turner (:dougt)]

Comment on attachment 129383 [details] [diff] [review]
patch

looks fine.

we probably should factor setup of all of the core xpcom services into a new
function, but i can refactor later.

Comment 4

[Mike Kaply [:mkaply]]

Comment on attachment 129383 [details] [diff] [review]
patch

a=mkaply for 1.5b

Comment 5

[Mike Kaply [:mkaply]]

Comment on attachment 129383 [details] [diff] [review]
patch

a=mkaply for 1.4.1 as well

Comment 6

[Mike Kaply [:mkaply]]

fix checked in to branch and trunk

Comment 7

[Stephen Walker]

reopening, this patch caused my opt windows thunderbird build to silently exit a
few seconds after starting.

Comment 8

[Darin Fisher]

building thunderbird now to see if i can repro the problem...

Comment 9

[Darin Fisher]

ok, my linux debug thunderbird build works fine.  no big surprise i guess, but
since i no longer have a WIN32 build environment handy i thought i'd at least
give linux a try.  i'm going to see about getting my WIN32 box building moz
tomorrow.

Comment 10

[Brian Ryner (not reading)]

I'm seeing this as well.  The key is to not have an existing compreg.dat.  The
problem is that in an optimized Firebird/Thunderbird build, we can hit the code
that tries to create the event queue service before we've ever registered
components.  This fails, and we bail out of main1().

SeaMonkey doesn't hit this (normally) because it uses a .autoreg file to force
component registration after you build in xpfe/bootstrap.  Perhaps we should do
this for "the birds" as well, but I think this exposes an underlying problem. 
Why can XPCOM not create instances of services that reside within the XPCOM
library before component registration happens?

Comment 11

[Darin Fisher]

maybe an alternate solution to this whole mess would be to make the
nsEventQueueService create the main thread event queue when it is first
initialized.  that might make the most sense since it would then happen lazily,
but always in time for whomever needs it (since everyone gets the event queues
through the nsIEventQueueService).

Comment 12

[Darin Fisher]

Attachment: v2 patch

this patch makes nsEventQueueServiceImpl::Init call CreateThreadEventQueue()

Comment 13

[Brian Ryner (not reading)]

Comment on attachment 129805 [details] [diff] [review]
v2 patch

Seems reasonable to me

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This patch caused mozilla -CreateProfile to fail on one of the mac tinderboxes 

Comment 15

[Darin Fisher]

thanks for mkaply for landing this patch.  marking fixed.

Comment 16

[Darin Fisher]

nevermind, this still isn't quite right...

Comment 17

[Darin Fisher]

Attachment: trivial fix

ok, the problem was that NS_InitXPCOM2 was just returning |rv| blindly...
whereas previously it would return the |rv| that resulted from
CreateThreadEventQueue.  if we reach the end of NS_InitXPCOM2, we actually want
to return NS_OK.

i tested this patch using an optimized thunderbird build under linux.

Comment 18

[Darin Fisher]

checked in last patch with a=mkaply

once trunk tinderbox goes green, i will land these changes on the 1.4 branch as
well.

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 129874 [details] [diff] [review]
trivial fix

This needs to go on the 1.4 branch as well.

Comment 20

[Darin Fisher]

3rd patch is now on the 1.4 branch

Comment 21

[Simon Paquet [:sipaq]]

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

Comment 22

[Bill Gianopoulos [:WG9s]]

OK.  So if these patches fix the problem, since my bug report of the same
problem in Mozilla Firebird was marked as a duplicate of this bug shouldn't the
patch be being applied to Mozilla Firebird (which still exhibits the bug even
with the 20030822 nightly) as well?

Comment 23

[Bill Gianopoulos [:WG9s]]

I just installed build 2003082304 and not only is this problem not fixed, butr
it has regresses to an even worse state.  Not only does hte autoproxy not work
for the loading the home page, but after waiting and trying ot load a page
requireing the proxy later on does not work.  Even entering Edit -> preferences
-> Advanced -> proxies and selcting Reload the automatic configuration does not
work.  he only thing that appears to make it use a proxy pac file is to re-enter
the URL.

Comment 24

[Bill Gianopoulos [:WG9s]]

Please ignor comment #23.  Re-installing the same nightly I had the probelm with
fixed the issue.

Comment 25

[Bill Gianopoulos [:WG9s]]

Please ignore comment #22.  My Firebird bug has been reclassified as NOT being a
duplicate of this bug, but instead a duplicate of Bug #100022 which is still open.