Community
Participate
Working Groups
0.4 M1 I have been seeing this error when migrating between builds. User should never need to manually resolve such problems so I would like to understand the root cause. I just had this problem on localhost. I checked the Plugins view, and I see taskPlugin.html had a service registered with pattern, "http://localhost:8080/task". I reloaded the plugin, and now it has a pattern, "/task". I'm wondering why this pattern is changing across reloads of the plugin. Is it because this attribute is dynamically computed and isn't suitable for caching? Do we need a way for plugins to specify if they have dynamic attributes that can't be cached?
How can I load this taskPlugin.html?
The metadata for a plugin is cacheable for the purposes of lazy loading however whenever a plugin is loaded we check and potentially update the cache. The only time you really need to manually force a reload is when the plugin will never get loaded otherwise. We're likely caching this metadata too long though and need to mark it stale and do an update/re-validate in the background to make sure what we're caching is an accurate reflection of what the plugin wants us to know about.
I was able to succeed with the following procedure: 1. Open Chrome Devtools, Ctrl+Shift+C, 2. Open devtools options, Gear menu bottom RHS 3. Net > Disable Cache << probably critical 4. open localhost:8080, 5. localStorage.clear() << probably does nothing 6. Cntrl+Shift+R to reload 7 login repositores now works, plugin is loaded. We should see if this issue is related to Chrome. I tried with Firefox and succeeded, but it was with a fresh profile so I don't know if it is browser related.
(In reply to comment #3) > We should see if this issue is related to Chrome. I tried with Firefox and > succeeded, but it was with a fresh profile so I don't know if it is browser > related. It's possible. We have found Chrome to be more aggressive about caching iframe content (and not clearing them on explicit page reloads). But we need to make sure we are setting the right cache control headers on our server before we blame the browser caching.
(In reply to comment #0) > 0.4 M1 > > I just had this problem on localhost. I checked the Plugins view, and I see > taskPlugin.html had a service registered with pattern,\ I just want to point out that in my case this problem was much worse. I had not taskPlugin so I can not reload it. I was completely broken and what's more I coudl not go back to 0.3 either.
I have to say I've changed once pattern from full path to relative path and this probably caused the problem you, John had. This happened once and I am not planning to change it unless solution of Bug 366700 will require it. For some reason I didn't have this caching problem, probably I had cleaned cache in between for some other reason. The problem JJB had is much different, because he didn't have taskPlugin installed at all. I added taskPlugin to defaults.pref and I was sure that this is enough to force Orion to install it if it's not installed. On FF it got installed with the first refresh. This file is loaded in preferences.js, I can see it uses some kind of a cache based on localStorage.
(In reply to comment #6) > The problem JJB had is much different, because he didn't have taskPlugin > installed at all. I added taskPlugin to defaults.pref and I was sure that this > is enough to force Orion to install it if it's not installed. On FF it got > installed with the first refresh. This file is loaded in preferences.js, I can > see it uses some kind of a cache based on localStorage. In my case I saw many console error messages related to defaults and or preferences. But I don't know how many of these are normal.
The WebInspector network "disable cache" was not enough for the case where I did not have taskPlugin.html. Only when I issued localStorage.clear() did it arrive. Then the git-clone.html page began to work. It seems to me that if a page needs a plugin, then the page should have an error message if the plugin is not present.
I was able to reproduce today and noticed the default.pref file was being returned from the browser cache instead of refetching it. I noticed a typo in our cache rules in server.configurator/plugin.xml We have a rule for "*.prefs" files which should oinstead be "*.pref" so that it will match default.pref. Net result is that we were at the mercy of the browsers (aggresive) caching rules instead of our own. I'll make the change in the main trunk however we might consider fixing this on OrionHub to stop the stream of associated problems.
I'll verify tomorrow in the nightly before marking fixed.
(In reply to comment #9) > I was able to reproduce today and noticed the default.pref file was being > returned from the browser cache instead of refetching it. I noticed a typo in > our cache rules in server.configurator/plugin.xml > > We have a rule for "*.prefs" files which should oinstead be "*.pref" so that it > will match default.pref. Net result is that we were at the mercy of the > browsers (aggresive) caching rules instead of our own. > > I'll make the change in the main trunk however we might consider fixing this on > OrionHub to stop the stream of associated problems. I bet this may also solve Bug 366902
*** Bug 369412 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > We have a rule for "*.prefs" files which should oinstead be "*.pref" so that it > will match default.pref. Net result is that we were at the mercy of the > browsers (aggresive) caching rules instead of our own. It turns out this fix wasn't sufficient to fix the problem. The problem is that we store plugin metadata in localStorage after the first time we fetch it. We need to add our own cache timer and expire that metadata periodically to be sure we pick up updates from the server. Simon has done something similar for prefence metadata already so will do the same for plugin metadata.
*** Bug 369281 has been marked as a duplicate of this bug. ***
This was fixed for M2. Plugin metadata now expires after one hour.
