Community
Participate
Working Groups
Orion 0.2 RC3 1. Install a plugin located on a hosted site (127.0.0.2) into your Orion client. 2. Restart the server (which will terminate the hosted site). 3. Clear cache and localStorage, then log into Orion again. 4. It will attempt to load the nonexistent plugin and hang for a long time until the request times out. This happens every time you access the navigator. There is no obvious way to remove the plugin since it doesn't appear in the Plugins list.
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.
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.
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.
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.
