Bug 350275

Comment 1 Simon Kaegi 2011-06-24 11:15:39 EDT

This is not great but I think the situation is synthetic enough to not hold back 0.2 but still experimenting here as the hanging is pretty bad.

FWIW the most simple workaround I can think of is to update pluginregistry.js so that the plugin data on a load timeout is set to {}.

e.g.
this._load = function() {
	if (!_channel) {
		_channel = internalRegistry.connect(url, _responseHandler);
		window.setTimeout(function() {
			if (!_loaded) {
// start fix
				data = {};
				internalRegistry.updatePlugin(_self);
// end fix
				_deferredLoad.reject(new Error("Load timeout for plugin: " + url));
			}
		}, 15000);
	}
	return _deferredLoad.promise;
};


First, to avoid hanging we need to be more careful in the UI about waiting for everything before proceeding. In many cases we should instead react to things getting loaded.

Without clearing localStorage what would normally happen is that you could go to the list page and uninstall it because we would use the cached plugin information to display and you could then uninstall it. In this case we're hosed because the cache is gone.

What we "should" be doing is when we get a timeout updating the cache with something like "{}" or perhaps something like a "load.timeout" service so we can find these more easily and not try and reload all the time. The other thing we need to add is "expires" metadata so we re-get every day or so.

Comment 2 Simon Kaegi 2011-06-24 12:13:11 EDT

This is a more serious problem than we thought initially. I really think we need to do something for RC3 and am now working with Boris and John on a minimal fix.

Comment 3 Simon Kaegi 2011-06-24 12:25:27 EDT

For RC3 we've done the minimal fix as described in comment 1 and done a label change in the Registry Tree to signal to the user that the plugin needs to be checked and potentially reloaded.

I'll clone this bug for a better fix in 0.3.

Comment 4 Simon Kaegi 2011-06-24 15:12:29 EDT

One of the tests was failing because of slightly different handling during install of a plugin with a 404. We noticed this during review but felt it was harmless enough at this point. I think the test was correct in this case so I have adjusted the patch with Boris reviewing to keep the old behavior for user installed plugin.