Bugzilla – Full Text Bug Listing
| Summary: | [ui] Available Software refresh occasionally yields blank results | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Matthew Piggott <matthew> | ||||
| Component: | p2 | Assignee: | Susan McCourt <susan> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | john.arthorne, Mike_Wilson, pascal, susan | ||||
| Version: | 3.4.2 | Flags: | Mike_Wilson:
pmc_approved+
|
||||
| Target Milestone: | 3.4.2 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Matthew Piggott
I'll investigate this. Definitely something odd going on, but it's not related to the filter text. Almost any action that causes refresh of the view will bring the data back. renaming title to reflect problem. I just saw this when starting 3.4.2, and simply switching from site to category view. The view went blank, switching again fixed it and then it seemed to work. Refreshing (as Matthew originally reported) can consistently cause it when in name or category view, and it can be fixed by either cycling through view by, refiltering the list, or open/closing the dialog. I also notice this: in the refresh scenario, the list refreshes, then the progress bar indicates activity while the repos are reloaded. Once the repos are reloaded, there is a scroll bar dance but no content showing. I'll need to debug this one, it does seem like a regression. This regression is caused by the "fix" for bug 250325. Bug 250325 attempted to address the infrequent/difficult to reproduce scenario whereby repos were loaded for the first time and occasionally the category list was duplicated. My proposal at this time is to back out the fix. - The fix ensured that model elements doing a deferred fetch only collect their children once, to prevent the duplicate accumulation that could occur - The incorrect assumption was that when a repo was refreshed, the viewer input model element would be replaced and the refreshed children would again be collected - The problem is that in the 3.4.x stream, it's possible that the viewer gets refreshed after the viewer input is replaced and before the repos reload. If this happens, the first refresh collects nothing and the second refresh (after the repos are reloaded) is ignored. Note that backing out the fix restores the code to its state in 3.4 and 3.4.1, it is not introducing new code. Created attachment 123434 [details] patch This patch backs out the fix for bug 250325 and restores the class to the revision used in R3.4 and R3.4.1. Two different scenarios that can be reproduced: SCENARIO 1: - Start the 3.4.2 build (only happens first time...) - Software Updates... - Available Software Tab - Open the view menu (the triangle menu adjacent to filter box) - If you are currently viewing by site, switch to category or name. If you are currently viewing by category or name, switch to site. BUG: The list goes blank. WORKAROUND: switching back to the previous view will correct it. Switching between name and category view will not correct it. This scenario consistently happens the very first time the dialog is opened after Eclipse is started. It will happen any time the dialog is opened when repos are not yet loaded. Since repos are kept via weak reference, it's arbitrary when/if the problem will reappear on subsequent opening of the dialog. SCENARIO 2: - Software Updates... - Available Software Tab - Use the view menu to set the view to category or name view. - Press Refresh... button BUG: List will say "Pending...", then it will empty, eventually it will repopulate with the previous content, and progress will continue to indicate at the bottom of dialog. When progress indication is complete, list goes empty. WORKAROUND: You must either refilter the list, or you can switch between Site and Category/Name view twice. (ie, switching to site view it is still empty, switching back corrects it). I have verified that the patch (which reverts bug 250235) solves these scenarios and note that I never saw the original problem (dup categories) while exercising these scenarios. Requesting PMC approval to fix this bug. The current behavior seems more bogus than the old behavior. Ok to apply patch that reverts to old behavior. fixed and tagged for next M-build, >20090123. Will verify in next build. |