Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.3+) Gecko/20010909 It would seem that if I have a PAC file specified (http://rcras.central.sun.com/proxy_config/central.pac) .. It will work for the session that I specified it in, but if I close mozilla and try to start it again, it won't start. The mozilla-bin processes are running (and seem to be idle) but I see no mizilla screen. I have let it sit several minutes. Netscape 4.78 (which I am on now) seems to be just fine with the same setting... It is DEFINATELY the AutoConfig URL because I edited the prefs.js file and removed it.. then mozilla starts fine. Incase it matters.. I am using profile manager because I have a "Internet" config and a "VPN" config. Thanks, Tommy

Cri, -> Networking. I'll take a look when I have a build. This would be a regression.

btw, it works fine as file:///home/tommy/central.pac it just doesnt seem to like http :p Tommy

Tommy, have you got any other builds lying around from the past week or so? Getting an idea of when this broke would be cool. Thanks.

It is also broken in the mozilla-0.9.3-1 (rpm) release. I will see if I can get an older build installed to see if that "fixes" it :) Btw, this is Redhat 7.1.94 (roswell2) I dont think that should matter though. Tommy

It works on my Seawolf box (RH 7.1) Mozilla/5.0 (X11; U; Linux 2.4.3-12 i586; en-US; 0.7) Gecko/20010316 [tommy@stan tommy]$ rpm -q mozilla mozilla-0.7-15 BUT ITS SOOOOO SLOW :) Tommy

Heh. Mozilla didn't really support PAC before 0.9 or so :) This is interesting. I can start up ok using a http:// PAC url in 0.9.3. Umm, wait. Ok, it currently appears that if I start with ./mozilla -P profilename it works fine, but if I just run ./mozilla and select 'profilename' from the profile manager, it doesn't come up.

Confirming. If I delete the pref, I can start fine from the profile manager. But with the pref, no love.

hehe thats why I said it "appears" to work.. as it starts, but I cant verify it was using the proxies cause its not on the VPN. I am doing the latter (mozilla, and choose from the profile manager) Tommy

Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.2) Gecko/20010701 [root@stan /root]# rpm -q mozilla mozilla-0.9.2-0 [root@stan /root]# (SAME RESULTS) [tommy@stan tommy]$ mozilla ProfileManager : StartApprunner profileName passed in: Sun (hangs) ^c [tommy@stan tommy]$ [tommy@stan tommy]$ [tommy@stan tommy]$ mozilla -P Sun ProfileName : Sun (works fine)

attempting to clarify the summary.

Interesting. LoadPACFromURL gets called with what looks like the right URL, but the nsIStreamListener callbacks don't ever seem to fire. cc'ing bbaetz.

I found a working version Mozilla/5.0 (X11; U; Linux 2.4.7-6 i586; en-US; rv:0.9.1) Gecko/20010607 [tommy@kyle old-mozilla]$ ./run-mozilla.sh MOZILLA_FIVE_HOME=. LD_LIBRARY_PATH=.:./plugins LIBRARY_PATH=.:./components SHLIB_PATH=. LIBPATH=. ADDON_PATH=. MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= Registering plugin 0 for: "*","All types",".*" New location for profile registry and user profile directories is -> /home/tommy/.mozilla ProfileManager : StartApprunner profileName passed in: VPN PAC:Loading PAC from http://rcras.central.sun.com/proxy_config/central.pac I am inside the initialize Hey : You are in QFA Startup (QFA)Talkback loaded Ok. PAC:Proxy = PROXY cache-brm.Central.Sun.COM:8080;PROXY webcache1.Central.Sun.COM:8080;PROXY webcache.Ebay.Sun.COM:8080 PAC:Proxy = PROXY cache-brm.Central.Sun.COM:8080;PROXY webcache1.Central.Sun.COM:8080;PROXY webcache.Ebay.Sun.COM:8080 PAC:Proxy = PROXY cache-brm.Central.Sun.COM:8080;PROXY webcache1.Central.Sun.COM:8080;PROXY webcache.Ebay.Sun.COM:8080 (etc etc etc)

Hmm. LoadPACFromURL gets called when you use hte profile manager? Is asyncOpen throwing an exception of some sort?

Doesn't appear to be -- I put the whole thing in a try block and don't come up with anything. In fact, netstat shows that the tcp connection opened to download the PAC has reached the ESTABLISHED state. Also, this is inexplicably working 30% or so of the time in my debug build. Race condition anyone?

Using the nsHttp:5 log, I compared traces launching from profile manager and with a profile specified on the command line. They appear to be basically idential up through |nsHttpConnection::OnStopRequest|, and adding the connection to the idle list. The the trace from the profile manager test just stops, while the other continues through the |nsHttpChannel| code. I'll post the traces. Reassigning to Networking::HTTP.

By the way, these traces are from a pretty old build -- last pulled around 0820. Since according to the reporter, this bug appeared sometime between 0.9.1 and 0.9.2, I'm hoping they'll still be somewhat useful.

That looks odd. I wonder if its something to do with initialisation order being different, maybe with the cache? I can't test at the moment, though. darin, any ideas?

darin

since this bug depends on whether or not the profile manager is displayed, i suspect that an event queue is being pushed on top of the initial event queue that was active when the PAC download request was initiated. this problem has hit us many times in the past. cc'ing danm for comments.

-> 0.9.8

punt -> mozilla1.0

Clarified summary.

can someone confirm this bug using a recent nightly build... 0.9.2 was a long time ago ;-)

tested on a CVS trunk build from today (march 18, 2002) and remote PAC seems to work just fine... even when the profile manager comes up. hmm.. perhaps this is some problem specific to the way events are processed under linux.. investigating.

yup, this is quite trivial to repro on linux (build 2002-03-06).

nsEventQueueService::GetYoungestEventQueue should return the youngest *active* event queue, not the youngest event queue. this patch also fixes what looks like a typo in nsEventQueueService::PushThreadEventQueue.

Comment on attachment 75217 [details] [diff] [review] v1 patch Interesting problem: the second part of this patch seems harmless and good to me. The first part has already been checked in in rev 1.34. So given that, I should just approve this patch. But the part from rev 1.34 does frighten me. I'm concerned because it will make ProcessPendingEvents ignore any events on the youngest queue if that queue has already been deactivated. So for instance this pattern (from nsImapProtocol.cpp) queue->StopAcceptingEvents() queue->ProcessPendingEvents() (...done with queue...) could conceivably leave events unprocessed if there are no pending events on elder queues at the time, but there are some on the youngest. This worries me. What do you think, Darin? I'd be more inclined to either (1) add a new method to the interface of EventQueueService explicitly for getting the youngest active queue or (2) move appshell initialization up earlier in application bootstrap. However, the scary part of the patch is already in! Hmmm.

Comment on attachment 75217 [details] [diff] [review] v1 patch OK, talking with Darin ... My above example isn't actually a problem, but we have identified other similar situations that could be a problem. (A ProcessPendingEvents loop in which the queue whose events are to be processed is refetched from the EQService each time.) However, that's silly and inefficient and we believe no one is doing that. So our best knowledge is that there is potential for dropped events from this patch, but only in an unlikely scenario involving abuse of the queues. We still think the patch deserves watching, but let's keep it.

well, since this patch seems like the right thing, and since it.. kind'a.. slipped in with.. my nsIChannel changes.. i'm going to mark this bug fixed ;-)

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

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

VERIFIED: fixed for a long time, but specifically mozilla 1.0 RC 1 and RC 2.