Bugzilla – Full Text Bug Listing
| Summary: | Push confirmation dialog stays in background / progress | ||
|---|---|---|---|
| Product: | [Technology] EGit | Reporter: | Frank Jakop <frank.jakop> |
| Component: | UI | Assignee: | Thomas Wolf <twolf> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | twolf |
| Version: | unspecified | ||
| Target Milestone: | 4.5 | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://git.eclipse.org/r/77820 https://git.eclipse.org/c/egit/egit.git/commit/?id=bece49f2f67eaac2b91e89848723d85180c6eb9b |
||
| Whiteboard: | |||
|
Description
Frank Jakop
Works as designed. Push (and fetch) may run in a background job. Throwing result dialogs at the user from background jobs is problematic. First, it's IMO not good UI design; it interrupts whatever the user may be doing by the time the job finishes. Second, there've been numerous bugs in the past where these asynchronous dialogs would interfere with modal dialogs open at the time, resulting in a UI deadlock. See e.g. bug 495512 (which explains why we did this), bug 493559, bug 492810, bug 487209, bug 487051, bug 485059, bug 484623, bug 480324, bug 475623, bug 391182, and possibly more. Now, if the push is not run in the background (i.e., when the job progress dialog is still open), then the result dialog should appear once the job is done. But if the user backgrounds that ("Run in background"), then we do open the result dialog only upon user interaction, i.e., when the user clicks the "Show push results..." link in the progress view. (Or the indicator in the bottom right-hand corner of the Eclipse window.) Ok, seems to make sense from that point of view, but as mentioned in https://bugs.eclipse.org/bugs/show_bug.cgi?id=495512#c4 a configuration option would be nice. We're using 'Commit & Push' for years with over 100 developers and never experienced a deadlock, whereas the danger of not recognizing a rejected non-ff-push is real and seen way more often. I also do not like buggy behaviours, would a config option for synchroneous push solve the problem for either use case? (In reply to Frank Jakop from comment #2) > Ok, seems to make sense from that point of view, but as mentioned in > https://bugs.eclipse.org/bugs/show_bug.cgi?id=495512#c4 a configuration > option would be nice. > > We're using 'Commit & Push' for years with over 100 developers and never > experienced a deadlock, whereas the danger of not recognizing a rejected > non-ff-push is real and seen way more often. > > I also do not like buggy behaviours, would a config option for synchroneous > push solve the problem for either use case? It would, but I don't like that very much. But how about the following: When the push was not successful, we make the job return a FAILED status. The Eclipse status framework can handle popping up modal error dialogs from background jobs fine. (We have trouble with our normal push/fetch result dialogs because they're not modal -- or maybe we've all been doing something wrong.) That way the user gets notified of failed pushes, and can then go to the progress view and open the EGit push result dialog to see the details. If we could even add a link into that error pop-up to open the push results dialog directly, that'd be even nicer, but I don't know off-hand if that's possible at all. That sounds like a reasonable solution. Can we assure that the most recent push is the topmost one in history view (at the moment this is the case), so the user will not have to scroll down to see a failed push? Thinking further, do you plan to remove the pull confirmation also? That would make the user unaware whether it produced a ff or not. (In reply to Frank Jakop from comment #4) > That sounds like a reasonable solution. Can we assure that the most recent > push is the topmost one in history view (at the moment this is the case), so > the user will not have to scroll down to see a failed push? I don't know in which order the progress view shows jobs. I would assume that the status indicator in the bottom right-hand corner is a stack and shows statuses in the order the jobs finished. > Thinking further, do you plan to remove the pull confirmation also? That > would make the user unaware whether it produced a ff or not. While pull also uses a job and show its results asynchronously, we have not received (AFAIK) any bug reports relating to this result dialogs. The difference is that this job runs with (parts of) the workspace locked, and I presume that leaves far less opportunities to the user to do something that would cause a similar modal deadlock. Push and fetch don't have any workspace locks. So: no, until we get reports about similar problems there I have no plans to change the result reporting of the pull operation. New Gerrit change created: https://git.eclipse.org/r/77820 Gerrit change https://git.eclipse.org/r/77820 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=bece49f2f67eaac2b91e89848723d85180c6eb9b |