Closed Bug 215457 Opened 21 years ago Closed 21 years ago

PAC: Autoproxy does not work first time browser is started

Categories

(Core :: XPCOM, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: jhpedemonte, Assigned: dougt)

References

Details

(Keywords: fixed1.4.1)

Attachments

(3 files)

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.
Attached patch patchSplinter Review
This patch was suggested by Dougt.  It moves the creation of the EventQueue to
right before the component registration.
Attachment #129383 - Flags: review?(darin)
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 :-)
Attachment #129383 - Flags: review?(darin) → review+
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.
Attachment #129383 - Flags: superreview+
Comment on attachment 129383 [details] [diff] [review]
patch

a=mkaply for 1.5b
Attachment #129383 - Flags: approval1.5b+
Flags: blocking1.5b+
Comment on attachment 129383 [details] [diff] [review]
patch

a=mkaply for 1.4.1 as well
Attachment #129383 - Flags: approval1.4.x+
fix checked in to branch and trunk
Status: NEW → RESOLVED
Closed: 21 years ago
Keywords: fixed1.4.1
Resolution: --- → FIXED
reopening, this patch caused my opt windows thunderbird build to silently exit a
few seconds after starting.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
building thunderbird now to see if i can repro the problem...
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.
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?
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).
Attached patch v2 patchSplinter Review
this patch makes nsEventQueueServiceImpl::Init call CreateThreadEventQueue()
Attachment #129805 - Flags: superreview?(bryner)
Attachment #129805 - Flags: review?(dougt)
Comment on attachment 129805 [details] [diff] [review]
v2 patch

Seems reasonable to me
Attachment #129805 - Flags: superreview?(bryner) → superreview+
Attachment #129805 - Flags: review?(dougt) → review+
Attachment #129805 - Flags: approval1.5b?
Attachment #129805 - Flags: approval1.4.x?
This patch caused mozilla -CreateProfile to fail on one of the mac tinderboxes 
Attachment #129805 - Flags: approval1.5b?
Attachment #129805 - Flags: approval1.5b+
Attachment #129805 - Flags: approval1.4.x?
Attachment #129805 - Flags: approval1.4.x+
thanks for mkaply for landing this patch.  marking fixed.
Status: REOPENED → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → FIXED
nevermind, this still isn't quite right...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached patch trivial fixSplinter Review
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.
Attachment #129874 - Flags: superreview?(bryner)
Attachment #129874 - Flags: review?(dougt)
Attachment #129874 - Flags: review?(dougt) → review+
Attachment #129874 - Flags: superreview?(bryner) → superreview+
checked in last patch with a=mkaply

once trunk tinderbox goes green, i will land these changes on the 1.4 branch as
well.
Status: REOPENED → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → FIXED
Comment on attachment 129874 [details] [diff] [review]
trivial fix

This needs to go on the 1.4 branch as well.
Attachment #129874 - Flags: approval1.4.x+
3rd patch is now on the 1.4 branch
*** Bug 216329 has been marked as a duplicate of this bug. ***
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?
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.
Please ignor comment #23.  Re-installing the same nightly I had the probelm with
fixed the issue.
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.
Blocks: 224532
QA Contact: scc → benc
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: