Bugzilla – Full Text Bug Listing
| Summary: | [ui] I can install something while an installation is proceeding | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Pascal Rapicault <pascal> |
| Component: | p2 | Assignee: | Susan McCourt <susan> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | simon_kaegi, susan |
| Version: | 3.5 | ||
| Target Milestone: | 3.5 M4 | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
|
Description
Pascal Rapicault
This might be a regression, the UI keeps track of what provisioning operations are running and grays out the buttons to prevent duplicates. There may be an enabling problem in the actions as they did change in M4. This regressed in M3 with the new workflows. The update/uninstall actions on the Installation Information page do the right thing. However the new command handlers for Check for Updates and Install New Software do not check this condition and they should before ever allowing the wizard to come up. Good news here is that rather than simply disabling them, we can put up an informational message telling the user that they can't do this until the current operations are complete. The fix is not risky as it is prechecking a condition before running the normal code, and the condition is the same method we use everywhere else to ensure no parallel operations. - should also check the update button used by the automatic updater, I think it grays in this case but need to double check - I will construct an automated test case this week on all actions and handlers for this condition so we don't regress again. At the engine level the profile is locked while performing the set of operations. We also track the profile timestamp that's used to calculate the plan and will throw an exception if the plan is based on a profile with an older timestamp. In the situation described it's conceivable that the 2nd provisioning operation could be performed instead of the 1st however we cannot get into the situation where the 2nd operation goes ahead based on an incorrect assumption about the profile's contents. Note that a better possible approach is discussed in bug 218216. This bug covers the "band-aid" of the UI not letting it happen. hmmm....because of bug #250316, the only way now to get the list of sites is through Install New Software... Right now I am in the middle of an update and decided to export my site list to append to a different bug. I was able to do this fortunately...the proposed temp fix above wouldn't have let me get to the list of sites. > This may also be the source for the pb that Mike V. had with the revert dialog
> where he could click finish several times (see bug #257775)
This is a completely different code path but I'll look at this one also. The wizard is supposed to remain gray and unresponsive until the revert is complete, but something has changed...
Fixed in HEAD >20081209. I investigated disabling the handler but did not like it since it doesn't allow for an explanation of the problem. Neither did I like using a message "You can't do this" in the handler because this blocks the user from browsing software on sites, managing sites, etc. Instead, I catch this case whenever a wizard resolves a plan. I like this for several reasons: - from a code structure point of view, it is almost as if the planner caught the problem for me. So the code is in the right place. - the user gets a status message explaining why they can't complete the wizard - any plan that was computed during this time gets thrown out by the wizard since things could change once the the current operation is complete. The changes released appear more significant than they are because I added a new status code for provisioning requests, and this propagates to several helper classes and the NLS strings. The code changes are in the wizard superclass and the common resolution page. As for the revert issue, I opened a separate bug (Bug 258207) to track that one. |