GNOME Bugzilla – Bug 99923
Auto proxy doesn't load at startup again
Last modified: 2004-12-31 21:21:14 UTC
The old problem, that the automatic proxy configuration file isn't loaded at startup, occurs again. :-( conditions: - start page or session with URLs, that the host cannot reach directly - using the automatic proxy configuration (this URL is directly reachable) Starting galeon brings a boxe, that the startup-site (or the URLs in the session) could not be reached. Hitting Enter in the Location field opens the URLs successfully. It seems, that this is a time critical race condition, because it sometimes works as expected. Especially when using the session feature, this is really annoying. :-( Mozilla: 1.2 Galeon: 1.2.7
I can't repro this here, even loading a session on startup. The proxy autoconf is poked before session loading takes place and it works as far as I can see.
Hm, not so good. As I wrote, the error sometimes doesn't occur. So this could really be a race condition. Could it be, that some relevant functions are called parallel in threads? The problem is, that I don't know the reason for this problem, so I don't know what information are relevant to reproduce it. It could be the speed of the machine running galeon or the speed of the network connection. Maybe you have a real SMP machine and the threads are executed really parallel and so you get an other behaviour as you would get on a single processor machine.
As far as I can see, no, there is no multithreading to cause a race condition. The session loading is explicitly done after the synchronisation of the mozilla prefs. gconfd runs out of process (naturally) so you might think that it isn't properly initialised when it comes time to read the gconf prefs to sync over to mozilla, but if that was the case, the gconf access functions should fail and you'd observe galeon looking very odd indeed as the UI prefs would not be readable.
No, that's not completly right. Galeon loads the mozilla prefs (prefs_load()) before the session (session_history_load()) and there are no threads at this time. This is correct. The problem is, that the corresponding call into mozilla [1] doesn't load the proxy configuration at calling time, they just create an event [2] which will be executed later. So the function mozilla_reload_proxy_autoconfiguration(url) returns without really loading the auto proxy configuration. It seems, that the event is executed in parallel with other mozilla operations, e.g. loading the start page. And then there is the race condition. regards, christian [1] netwerk/base/src/nsProtocolProxyService.cpp: nsProtocolProxyService::ConfigureFromPAC [2] comment within the function [1]: /* now we need to setup a callback from the main ui thread in which we will load the pac file from the specified url. loading it now, in the current thread results in a browser crash */
This is happening for me on Red Hat Linux 9, Galeon 1.3.4, Mozilla 1.3.
*** Bug 121917 has been marked as a duplicate of this bug. ***
WONTFIX for 1.2. Updating the version to the latest release since there hasn't been any work on it, afaik.
*** Bug 78940 has been marked as a duplicate of this bug. ***
*** Bug 130143 has been marked as a duplicate of this bug. ***
*** Bug 145535 has been marked as a duplicate of this bug. ***
Any news on this one? I have the same problem (still 1.2.9 though). It seems to happen every time when I click "Recover" after an epiphany crash.
Sorry about that post. I searched the bug database and didn't relize the match was Galeon rather then Epi.
Unfortunately there is nothing we can do about this, as it is a problem inside mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=100022