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)
Core
XPCOM
Tracking
()
RESOLVED
FIXED
People
(Reporter: jhpedemonte, Assigned: dougt)
References
Details
(Keywords: fixed1.4.1)
Attachments
(3 files)
1.29 KB,
patch
|
darin.moz
:
review+
dougt
:
superreview+
mkaply
:
approval1.4.1+
mkaply
:
approval1.5b+
|
Details | Diff | Splinter Review |
6.11 KB,
patch
|
dougt
:
review+
bryner
:
superreview+
dbaron
:
approval1.4.1+
dbaron
:
approval1.5b+
|
Details | Diff | Splinter Review |
950 bytes,
patch
|
dougt
:
review+
bryner
:
superreview+
dbaron
:
approval1.4.1+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•21 years ago
|
||
This patch was suggested by Dougt. It moves the creation of the EventQueue to right before the component registration.
Reporter | ||
Updated•21 years ago
|
Attachment #129383 -
Flags: review?(darin)
Comment 2•21 years ago
|
||
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+
Assignee | ||
Comment 3•21 years ago
|
||
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 4•21 years ago
|
||
Comment on attachment 129383 [details] [diff] [review] patch a=mkaply for 1.5b
Attachment #129383 -
Flags: approval1.5b+
Updated•21 years ago
|
Flags: blocking1.5b+
Comment 5•21 years ago
|
||
Comment on attachment 129383 [details] [diff] [review] patch a=mkaply for 1.4.1 as well
Attachment #129383 -
Flags: approval1.4.x+
Comment 6•21 years ago
|
||
fix checked in to branch and trunk
Comment 7•21 years ago
|
||
reopening, this patch caused my opt windows thunderbird build to silently exit a few seconds after starting.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 8•21 years ago
|
||
building thunderbird now to see if i can repro the problem...
Comment 9•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
this patch makes nsEventQueueServiceImpl::Init call CreateThreadEventQueue()
Updated•21 years ago
|
Attachment #129805 -
Flags: superreview?(bryner)
Attachment #129805 -
Flags: review?(dougt)
Comment 13•21 years ago
|
||
Comment on attachment 129805 [details] [diff] [review] v2 patch Seems reasonable to me
Attachment #129805 -
Flags: superreview?(bryner) → superreview+
Assignee | ||
Updated•21 years ago
|
Attachment #129805 -
Flags: review?(dougt) → review+
Updated•21 years ago
|
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+
Comment 15•21 years ago
|
||
thanks for mkaply for landing this patch. marking fixed.
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
Comment 16•21 years ago
|
||
nevermind, this still isn't quite right...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 17•21 years ago
|
||
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.
Updated•21 years ago
|
Attachment #129874 -
Flags: superreview?(bryner)
Attachment #129874 -
Flags: review?(dougt)
Assignee | ||
Updated•21 years ago
|
Attachment #129874 -
Flags: review?(dougt) → review+
Updated•21 years ago
|
Attachment #129874 -
Flags: superreview?(bryner) → superreview+
Comment 18•21 years ago
|
||
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 ago → 21 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+
Comment 20•21 years ago
|
||
3rd patch is now on the 1.4 branch
Comment 21•21 years ago
|
||
*** Bug 216329 has been marked as a duplicate of this bug. ***
Comment 22•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
Please ignor comment #23. Re-installing the same nightly I had the probelm with fixed the issue.
Comment 25•21 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•