Community
Participate
Working Groups
Currently, diff computations required by the Compare Editor are run as IRunnableWithProgress in the given ICompareContainter which extends IRunnableContext. This works fine, but there is a small issue with it. If you quickly open several Compare editors from the Sync view and the first one starts to calculate its diffs a model dialog will pop up showing the progress. The problem is that if the dialog is up you can cancel only the computation for that editor, if another computation starts in the meantime there is no way to cancel it. A way out from this situation could be running diff computation as Jobs so the progress will be shown in the in the Progress View for each of the job separately. Another solution could be showing the progress inside the Compare editor as Dani suggested in bug 322329, comment 5.
Even though this bug looks like a blocker to bug 322329 I don't think a fix for this bug will be something we would like to backport to 3.6.x, which will eventually happen to bug 322329.
Consider a scenario when you've opened two compare editors. As soon as the "Finding diffs" dialog shows up you hit cancel on it. The first algo is cancelled, but does the other one do? Of course, it hasn't been cancelled so it's still running. What's interesting the modal dialog stays up for that time, even though it doesn't show any progress and the Cancel button is disabled (you've just hit it for the first algo). As the result you have to wait for the second algo to stop without a way to cancel it. Once bug 307280 is fixed this could become a serious issue for long running uncapped diff algorithms!
Prakash, you're an expert in that matter[1]. Is the above an expected behavior when we run multiple runnables via PlatformUI.getWorkbench().getProgressService().run(boolean, boolean, IRunnableWithProgress) (using ProgressManager in this particular case)? Or is there something wrong with our runnables or the way we run them? Is moving to Jobs the only option? [1] http://blog.eclipse-tips.com/2009/02/using-progress-bars.html
The major problem seems to be not passing the IProgressMonitor down and not honoring the cancellation. So even if the user presses Cancel, nothing happens. Now that the related Bug# 322329 is fixed, as soon as the user presses cancel (and the operation responds to it), the dialog should go away. Is that not happening now?
(In reply to comment #4) > Is that not happening now? It is, if you open a single compare editor. However if you schedule multiple comparisons (e.g. by opening files from the Sync view) you will get blocked with the dialog even though you have hit cancel on it. Apparently, the dialog is up as long as all scheduled runnabbles are running (see comment 0 and comment 2)
Created attachment 179509 [details] Patch that makes the "Finding diffs" dialog easier to observe
Created attachment 179510 [details] mylyn/context/zip
From my initial investigation there is wrong ProgressMonitorDialog$ProgressMonitor instance notified about cancelation. I observed, that cancleation works only for last compared document. In other words when your are comparing e.g. 3 documents, it only works when you hit cancel on when first two has been compared and third is comparing. It may suggest, that there is always cancelled last created thread (I did not check it, it is only my guessing.)
(In reply to comment #8) > It may suggest, that there is always cancelled last created thread I thought it's the other way round but I may be wrong. Anyway, can you confirm that the dialog is up blocking the user as long as long as at least one runnabble is running even though the Cancel has been hit? This is my major concern -- the blocking dialog with no way of closing it.
Tomek, I am confirming that for all compared documents except last one the dialog blocks any user actions I can click "Cancle" but once I click it, the button becomes inactive and I must wait until comparing ends. What I also observed, that for me there is only one IrunableWithProgress running at the time. Next runnable starts only when comparing previous files ended. Moreover when comparing many files, there is opened new progress dialog for each file. When we talked with Tomek today, he said he has only one progress dialog for all files. Tomasz, can you confirm that?
(In reply to comment #10) > When we talked with Tomek today, he said he has only one progress dialog > for all files. Tomasz, can you confirm that? Yes, I was pretty sure I was dealing with a single dialog. I had a chat with Prakash today during which he managed to reproduce the problem on his side. He also said that it looks like a single dialog. At the same time he hacked a sample plug-in that does the same thing Compare does with the Runnables but this time he got a separate dialog for each runnable. There is definitely something wrong going on here, and Prakash promised to take a closer look at it.
Tomasz, As I suspected, the IProgressService.run is called from two different threads. One checks whether its ok to open the editor and the other tries to computes the differences. When this (call from different threads to IProgressService.run) happens, and the user presses cancel, the UI appears to be frozen. I'm able to reproduce it without the team/compare coding. This is being addressed in the Bug# 326330
I'm holding off with targeting this bug to a particular milestone until bug 326330 gets addressed. If fixing that bug didn't solve the issue from comment 0, I would reconsider fixing this bug.
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. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
