User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20100101 Firefox/16.0 Build ID: 20121005155445 Steps to reproduce: Took a vanilla Thunderbird 13-16 install on OSX and added a MCD config (https://developer.mozilla.org/en-US/docs/MCD%2C_Mission_Control_Desktop_AKA_AutoConfig) pointing to a configuration file living on a http url. Sample config for testing; created; Thunderbird.app/Contents/MacOS/defaults/pref/autoconfig.js with content --- pref("general.config.obscure_value", 0); pref("general.config.filename", "autoconfig.cfg"); --- and created; Thunderbird.app/Contents/MacOS/autoconfig.cfg with content --- // It doesn't matter what it is but the first line must be a comment lockPref("autoadmin.global_config_url","http://example.ra09.com/autoconfig.js"); --- then tried to start Thunderbird (with the network cable disconnected, for the point of this example to replicate it disconnecting your network connection won't be needed since that global_config_url can't be resolved ) Actual results: Thunderbird hung solid and didn't complete loading or display any sort of error dialog. Expected results: Thunderbird should have attempted to access the http url and then after failing continued to load without the autoconfig script being loaded. (Which is the behavior in Thunderbird 12 and below) This regression is important for network administrators using MCD to setup prefs for Thunderbird installs running on laptops. the global_config_url http url will not always be accessible as the laptop roams around so having thunderbird be impossible to start if the connection to the work network isn't not available at the time is a big problem.
also noting in what is probably the same bug manifesting via another autoconfig option; I tried copying the main autoconfig lines that normally live centrally on the http url into the autoconfig.cfg file inside the thunderbird install to avoid needing to use global_config_url option to load them in. (which is non ideal since it means any change to autoconfig setup then has to be copied out to every thunderbird install but would be better than having tb freeze on startup when not connected to the corporate network). That mostly works but making use of the 'getLDAPAttributes()' function inside autoconfig.cfg will result in the same hang on startup of Thunderbird if it points to an ldap server that isn't currently accessible/resolvable. So it looks like whatever is going in isn't limited to the global_config_url option but instead is something deeper that has changed so that autoconfig options in general that access network resources no longer gracefully fail if they can't reach the remote host they point to.
I can confirm this also ... we're based on Thunderbird 14 at the moment, and I haven't been able to test newer builds, but we had an LDAP server that had an unresolvable DNS entry, and all of our Thunderbird users had hung processes. After the issue was fixed, Thunderbird still stuck around in the process list until killed and relaunched.
I can also confrim this in Thunderbird 24 ESR. It will hang it if the url cannot be resolved.
You need to log in before you can comment on or make changes to this bug.