Bugzilla – Full Text Bug Listing
| Summary: | [Progress] calls from multiple threads to IProgressService.run() causes empty progressMonitor windows | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Prakash Rangaraj <prakash> | ||||||
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | bokowski, daniel_megert, emoffatt, john.arthorne, kazm, pwebster, remy.suen, susan, Szymon.Brandys, tomasz.zarna, yevshif | ||||||
| Version: | 3.7 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||||
| Whiteboard: | stalebug | ||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 324993 | ||||||||
| Attachments: |
|
||||||||
We would like to have an eventual fix for this bug backported to 3.6.2. This issue is the last missing piece, we already have a preference to disable capping in the Compare editor (bug 307280) and an option to cancel long running diff computations (bug 322329). Without the fix we may get into trouble when multiple, long running (non-capped) comparisons are scheduled and there is no way to cancel them (see bug 324993 for more info). Created attachment 179725 [details]
Patch v01
Susan/Boris,
Any idea of why & where the nestingDepth is used?
This code has been there since the beginning of time. I don't think we can change close() to close the dialog even if nestingDepth is greater than zero - it would change the behaviour, and be counter to the JavaDoc on the close() method. However, it is not clear to me why this logic was put in there in the first place, let me think about it (and talk to others who might know). I'll add another comment once I know more. (In reply to comment #4) > This code has been there since the beginning of time. I don't think we can > change close() to close the dialog even if nestingDepth is greater than zero - > it would change the behaviour, and be counter to the JavaDoc on the close() > method. +1. > However, it is not clear to me why this logic was put in there in the > first place, let me think about it (and talk to others who might know). I'll > add another comment once I know more. Just a guess: maybe the dialog shows progress about something going on in the UI and allows to cancel the work. If for whatever reason the dialog closes, the UI might be blocked and the user can't do anything but wait. Not for this release. Will revisit later. This issue blocks some non-trivial work in the Compare component. It would be nice to have this UI issue fixed early in the cycle. Paul, who is on it now? Could you be more specific about the target milestone? Tomasz, since it blocks a major issue in Compare, I would consider changing the severity of this UI issue to major too. Szymon, Prakash is gone and I'm not really sure who has knowledge of the internals of this code anymore...Paul ? (In reply to comment #8) > Szymon, Prakash is gone and I'm not really sure who has knowledge of the > internals of this code anymore...Paul ? This bug blocks 3.8 work in Compare, see bug 326683. Paul, any plan to fix this in M4 or M5? If not, we would need to adjust our plan. I was asked to clarify the blocking dependency on bug 324993. This bug doesn't prevent us from switching diff computations to Jobs. If this bug was fixed we wouldn't have to it at all. In other words, either this bug or bug 324993 should be fixed. Looking at the work effort objectively I thought fixing the bug in the UI would be easier then switching to Jobs in Compare. At the same time, I'm not 100% sure that fixing the former will solve all the issues in Compare (bug 326680, bug 326683). After a quick look at this example I'm confused by the behaviour from a UI point of view. Is this dialog aggregating all of the work for all of the runnables into that one progress indicator? Or does it simply display the first runnable in, and leave itself open with no progress indication if there is a secondary runnable that is still running after the first is done? It seems to me that either: 1) canceling the "topmost" job should promote the next one to the single progress monitor that is displayed so you see its tasks, and disabling cancel can only be done if there's one job. Problem: what if 3 jobs like cancel, and 2 don't. Disabling cancel when you hit the non-cancelable jobs would prevent you from getting to any cancelable jobs left. 2) If there's more than one runnable it should switch to that dialog that displays one progress indicator per runnable, each individually cancelable (or not). But I believe that's a dialog for interacting with Jobs. I think that both of those solutions are outside of the resources we have for this area. PW This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |
Created attachment 179671 [details] Project to reproduce the bug When we press cancel for one Runnable, the window stays there till all the other runnables are over. Cancel button is disabled and no progress shown for other runnables. To the user it appears as if its frozen.