Bugzilla – Full Text Bug Listing
| Summary: | Sometimes reload required when first visiting orion.eclipse.org | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | John Arthorne <john.arthorne> | ||||||
| Component: | Client | Assignee: | Simon Kaegi <simon_kaegi> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | major | ||||||||
| Priority: | P2 | CC: | bokowski, ian.skerrett, mamacdon, nathan, simon_kaegi, susan | ||||||
| Version: | 0.2 | ||||||||
| Target Milestone: | 0.2 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 7 | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | 340612 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
|
Description
John Arthorne
I've have experienced this for M6. I was using Chrome and I have been using M5. JulianJ from IBM experienced this problem on both FF and Chrome in his first attempts to try Orion. He just got "Transferring data from orion.eclipse.org..." in a the browser and then "Done" but the screen was blank. On Chrome, shift/refresh fixed the problem. On FF, he was never able to refresh his way out of the problem, so he stayed with Chrome. Shift-Reloading doesnt really seem like the greatest thing to have to tell people to do. Could we use query keys on the javascript URLs to do some cache invalidation. See -> http://html5boilerplate.com/docs/#Version-Control-with-Cachebusting It's not a caching problem. The problem seems to be that the file plugin isn't loading in time. It is likely some kind of race condition or timing problem in our plugin/service initialization. Mark reported that in the failure case, fileClientPlugin.html wasn't getting loaded. Mark, can you start investigating this? I talked to Boris about us trying to push a fix early in eclipsecon week since people are going to be running into this. I can help, but figured you have a head start time-zone wise. The navigate-table glue code is not doing its initialization in the right order. At creation time, PluginRegistry needs a storage object to populate itself from. Normally this is localStorage, but on first visit localStorage is empty until the default preferences have been fetched from the PreferencesService. If we defer creation of the plugin registry until the preferences have been fetched, it fixes this. Nice job Mark. I think the only fix we can do short-term is as you describe. I created bug 340612 to look at maybe doing more in M7. Created attachment 191650 [details] patch for m6 Here is a patch against M6 (v20110311-1121) PluginRegistry is created inside a getPreferences().then() block that forces the default prefs to be loaded. The FavoritesService initialization is also moved into the same block; this is because there seems to be an issue with getPreferences() that causes the favorites to receive the wrong data if it's called while the first getPreferences() request is still in progress (see Bug 340614). Moving it inside makes the requests serial and avoids that. Created attachment 191711 [details] Patched compiled version of navigate-table.js Here's the patch from Comment #8 applied to the compiled M6 version of navigate-table.js. This file can be dropped into eclipse/plugins/org.eclipse.orion.client.core_0.2.0.v20110311-1121/static/js/compiled I have pushed Mark's fix to orion.eclipse.org. Mark, can you verify that it is fixed? I was never able to reliably reproduce this so don't have confidence that I can verify it. I just quickly tried on FF 4 and IE 8 and didn't have to refresh. Once the fix is verified I will also push it to orionhub.org. (In reply to comment #10) > Mark, can you verify that it is fixed? I can still reproduce the problem. I've tried reloading http://orion.eclipse.org/js/compiled/navigate-table.js but I don't see the changes from attachment 191711 [details] -- it looks like the same version of the file that was there before. We likely need to dust off this patch for M7 assuming there is no deeper structural change coming in bug 340612. I am wondering why in the patch only the favourites service is deferred until after the plugin registry is created. I imagine to be on the safe side, almost all the glue code needs to be deferred until the plugin registry is initialized. So the pattern would be: - create service registry - create preference service - wait for preference service to be initialized - create the plugin registry - Once plugin registry is loaded, do all the rest of the initialization work. I noticed Boris just released this in navigate.table.js: var fileServices = serviceRegistry.getServiceReferences("IFileService"); This will be broken unless it happens *after* the plugin registry is successfully loaded (or already cached). There may be other examples where service lookups are occurring that would need to be deferred. see also bug 334197. Fixed in HEAD. We'll continue to improve and formalize this stuff in M8 in bug 334197. . |