Bugzilla – Full Text Bug Listing
| Summary: | Git commit, Git status - pages with diff provider service not loading their diffs | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Susan McCourt <susan> |
| Component: | Client | Assignee: | Susan McCourt <susan> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | blocker | ||
| Priority: | P3 | CC: | libingw, simon_kaegi |
| Version: | 0.5 | ||
| Target Milestone: | 0.5 M1 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Susan McCourt
I think I caused this (see http://dev.eclipse.org/mhonarc/lists/orion-dev/msg01620.html) but I need Simon's help to decipher how the extension processing could possibly corrupt the registry/unregister a service. *** Bug 376642 has been marked as a duplicate of this bug. *** I had no issues with status page but commit page. Here is my steps. Clear all browser data. LocalStorage.clear(). 1. Go to orion.eclipse.org. 2. Go to settings page and reload all plugins. 3. Go to git status page and click on a commit. 4. At this moment the commit page shows blank compare widgets. 5. localstroage.clear() 6. Reload page. Now the page works fine. 7. Reload page again. The page got same errors. Basically you have to repeatedly do localStorage.clear() before every page reload. (In reply to comment #0) > The service that gets unregisters is the diff provider. If you > localStorage.clear() you can fix the problem but the next time you load the > page on Chrome you will see the problem again. Need to check if the behavior > is identical for Firefox. I am seeing the issue in both Chrome "18.0.1025.151 beta-m" and FF 11.0. (In reply to comment #3) > I had no issues with status page but commit page. My issue with the status page is: 1) ensure you have some staged or unstaged changes 2) open git status page, everything seems okay 3) select a diff 4) you get the service error. Commit page has different symptoms. It comes up but all the diffs are empty and you have the error for each diff shown in the commit page. The common thread is that the attempt to access the diffProvider service is failing. My hunch is that something I'm doing in the extension parsing (for example, for related pages) that is crapping out the service entry. I commented out related page processing and those pages fill in their diffs. So there's something happening in there that's corrupting the registry. I'm going to start commenting bits of code out to narrow it down. I think we've figured this out. The new changes to the extension parsing introduce the notion of validation regexp patterns, whose results can be referenced by a variable in a URI template. One optimization in this parsing is that we are caching some variable values as we run the validation regexp patterns against metadata, so that we don't have to recompute them when we build the URI. This caching of variable values is done in the validation property (which is in the metadata). Simon says this is a "bad thing" because it would cause the plugin to get reloaded. The related page contributions in gitPlugin.html use these variables and caching. So the git plugin is getting reloaded, and it is the plugin that defines the diff provider service. I'll investigate a caching mechanism that does not add properties to an existing service property. Not sure if it is helpful:
In git status page, at very first time when you click on a file there are two calls of the diffProvider.
getDiffContent.getDiffContent().then{getDiffFileURI()}
getDiffContent() was actually successful but after that the serviceRegistry was flushed out from id 10 to 14, where 14 is the diffProvider.
So now if you click any file again, the service is just not there.
Regarding "So the git plugin is getting reloaded", is the first call of the service triggering the reload? Otherwise, how come the very first call was OK ?
(In reply to comment #8) > Regarding "So the git plugin is getting reloaded", is the first call of the > service triggering the reload? Otherwise, how come the very first call was OK ? The problem was something like this: 1 - you make the first call to the diff provider 2 - meanwhile, the page target gets set which triggers related page parsing 3 - the extension code parses the validation properties of the related pages extension. While parsing, it was storing some cached regular expression matches in the properties so that it wouldn't have to recompute them when generating hrefs from those matches. 4 - now the metadata is changed (because the parsing code stuck a cache variable there) 5 - on every service call the plugin registry is checking to see if the metadata has changed. It detects the change and reloads the plugin. 6 - now you make the second call to the diff provider, and the service id is different. The fix was changing the extension parsing code to cache its values somewhere that is NOT in the metadata. Fixed with http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=5dea0adbbf96d18797d643bfa1c8ffb8f7fbfa80 |