Bugzilla – Full Text Bug Listing
| Summary: | [ui] validate repository URL before letting user add site | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | John Arthorne <john.arthorne> |
| Component: | p2 | Assignee: | Susan McCourt <susan> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | pascal, susan, the_Arioch |
| Version: | 3.4 | ||
| Target Milestone: | 3.4 M6 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | 207978, 211102 | ||
| Bug Blocks: | |||
|
Description
John Arthorne
We are validating the URL within the dialog already, at least we are using the URL constructor to let us know if it's malformed, etc. We need to do more here. I'm not sure about the parenting problem, that's weird. Will look into this, probably not for M2... Note the parenting problem was observed in both 3.3.1 and 3.4 M2 builds from this week. This seems to be the StatusHandler behaviour - it's not discovering that there is an active modal shell. just a note for what the current update manager UI is doing on validation... The local or archived sites button shows a dir or file dialog (as we do), but the name is validated when the user leaves that dialog, and if it's invalid, they are returned to the dir or file dialog. This isn't great, but at least the validation occurs before the user presses okay in the enclosing dialog. *** Bug 207998 has been marked as a duplicate of this bug. *** need to fix for M4. The problem of the wrongly parented error dialog is now fixed. The bigger problem is that I can't validate a repo URL without trying to load it, and loading it can be extremely slow. So I don't want to wait for the result in order to validate the dialog. What's needed to fix this better is either a significant improvement of the speed of loading (bug #207978) or, as John mentions in comment #0.. >This possibily >requires extra validation API on I*RepositoryManager. Opened bug #211102 for that part of it investigate for M5 *** Bug 212348 has been marked as a duplicate of this bug. *** Per bug #212348, there are now more specific exceptions for repo failures and these need to be propagated in the UI. Moving these to M6. I think it's better to test now than start tackling the error reporting problem. I intend to work on this during "dead time" at the end of M5 because these are important for SDK integration. Rechecked the various issues in this bug. Retitling this bug and removing milestone because the only remaining issue is John's original suggestion: >Even better would be to validate the URL within the dialog, and don't let the >user click "Ok" until a valid name/URL has been entered. This possibily >requires extra validation API on I*RepositoryManager. This depends on bug #211102. The issue here is that I don't want to try to load the repo until the user has clicked "OK" so having more specific statuses in the exception thrown by loadRepository doesn't help me. If there were API to check whether a repo is there and not load it, then I could do better with early validation in the add site workflow. The other issues that have come up along the way are fixed. - The wrong parent problem was fixed long ago. - The changes I just committed for bug #214640 handle the issue in comment #9 (reporting the specific repo load failures). Any clients catching ProvisionException now have to decide how that exception is reported by the status manager. Depending on who the caller is, the exception might be silently logged (when a background process encounters the problem), it might be shown by the status manager, or it might be shown in a local wizard error area. Marking M6 as there's some amount of validation I need to do in order to determine whether to auto-generate a repo for a watched location. Fixed in HEAD. Invalid local locations are detected when the user exits the file or directory dialog. The path is retained in the edit field, but the dialog stays in an error condition telling the user the URL is not valid. Note this is an improvement over today's UM, which detects it at the same time, but puts a message in your face and forces you back to the file or dir dialog. Validation of typed URLs (such as http://) is only done when the user tries to add the repo, since it can be expensive. Whereas before, the user could type "http://blort", push add, and then about 10 seconds later get a failure dialog telling them there is no repo there, they now have to wait the 10 seconds and then the dialog goes into an error state. I think the time is worth it, though, because in the old workflow, the user sees the repo get added to the dialog and then later gets an error message saying it was invalid. This is also an improvement over today's UM, which currently takes about the same 10 seconds to validate the URL (no hourglass and no way to cancel), and then adds the site anyway. Overall I think this plays a lot better now. Better than previous p2 UI, and better than the same UM workflows. Note: We had to back out the validation of repo URL's due to UI hangs that can occur when the repository itself tries to prompt the user. The UI now has the original behavior, whereby simple validations are done with the URL but the URL is not contacted. If the user adds an invalid repo, they'll find out the first time it tries to load (such as when they expand it in a list). See bug #225062 for details. *** Bug 241304 has been marked as a duplicate of this bug. *** |