Community
Participate
Working Groups
Cursor jumps to the top when modifying files in compare editor 1. Compare two files 2. Scroll down a bit 3. Copy something from left editor 4. Paste in right editor 5. Click on the left editor (intending to copy another piece of text) 6. Editors are scrolled to the top of first different block It's mighty irritating when user needs to copy a lot of strings between editors and they're somewhere down the file.
I've had a look at this and it appears that the unwanted scroll to the top only happens the first time. It is due to the use of synchronized scrolling and is triggered by a viewport event from the source viewer. It only happens when both sides are editaqble which is unique to Comapre with Each Other. Given the complexity of the problem and the fact that it is an isolated case, I don't feel that we need to address this in 3.3. One thing that would help is to make the Synchronized Scrolling an option you can turn on and off in the merge viewer. It is currently only settale in the global preference page.
Isn't it related to bugs #84173, #92255 and #140122 (they all look like dupes)?
*** Bug 92255 has been marked as a duplicate of this bug. ***
*** Bug 140122 has been marked as a duplicate of this bug. ***
I think I know the source of this bug. I have copied the compare UI code for use in another project and fixed the bug there. I do not know if this resolution really applies to the original Eclipse compare editor, but I believe so. The source of the problem: In synchronized scrolling mode the source viewers' scrollbars are hidden and a common simulated scrollbar is shown instead. After the loading of the editor, this common scroll bar displays the correct position. However the scrollbars of each StyledText widget (which, being hidden, are still used by the widget to determine scroll offsets) have incorrect offsets. After you do any scrolling, the internal hidden scrollbar is updated with the correct position and is kept up to date thereafter. How to verify the source of the problem. If you make the StyledText's scrollbars visible (resulting in 3 scrollbars displayed -- two viewers' and one common), you will see the fact of incorrect positioning with your own eyes. Fixing. In TextMergeViewer, there is a method called updateContent. At the very end of it, there are such lines: if (selectDiff != null) setCurrentDiff(selectDiff, true); else selectFirstDiff(); If you invoke them via Display.asyncExec, the problem goes away. In my code, I've replaced them with: final Diff selectedDiff = selectDiff; getControl().getDisplay().asyncExec(new Runnable() { public void run() { if (selectedDiff != null) setCurrentDiff(selectedDiff, true); else selectFirstDiff(); } }); Again, I have not verified this resolution, it just works for me with my private copy of Eclipse compare UI. Andrey Tarantsov, xored software, Inc. <andreyvit@xored.com>
Created attachment 53971 [details] Should be applied to org.eclipse.compare; fixes this bug Adding a patch for this bug. Checked with 3_2_mainenance brach. Patched jars for 3.2 and 3.2.1 are available from my page at http://andreyvit.googlepages.com/eclipsecompareuipatch.
...Have reread the bug description more thoughtfully. The initial reproducing steps are strange, but the title ("With Compare with Each Other, unwanted scroll to top") is just what I intended. So, to be sure, the exact steps to reproduce the fixed bug are: 1. Compare two files several screens long and with the first difference being somewhere in the middle 2. Click on one of the editors to activate it 3. Use your mouse wheen to scroll it in any direction The editor immediately scrolls to the top, though it was expected to scroll just a few lines forward or backward.
You're right, the first bug report seems something else but your patch fixes at least my Bug 140122 :-)
Yes, but other bugs that describe exactly what I fixed, including your 140122, were marked as duplicates of this one. So I consider this bug to include those.
Max, can you confirm that this fix in fact solves your original problem, too?
Sorry for taking so long to comment on this but I've been swamped lately. First of all, I want to say thank you for providing patches for this. We appreciate the effort. However, I have a couple of issues with the provided patch. First of all, it is against the 3.2 maintenance branch. The code in HEAD has changed considerably since then. As a matter of fact, I have tried the scenario in 3.3 and it no longer fails (using build I20061114-1636). I suspect it was fixed when we added code that would maintain the current selection and position if the viewer was being refreshed. Given the subtle nature of this bug, I would be helpful if those copied on this bug could verify this for all the scenarios where the problem has appeared. The other issue I have with the patch is that it fixed a problem by essentially delaying when a piece of code was performed. The problem is that delaying that code may have introduced other problems that would have been equally subtle.
I checked this bug with I20061102-1715 and I20061114-1636 and I confirm it's fixed. However the suspicion that this bug is the same as the ones marked as duplicates was wrong -- I tried two scenarios: synchronize file with CVS repository and compare two disk files and view is still scrolled to the top in both cases.
You are right. In the end, there were two bugs. However, initially, the symptoms were very similar and hence the marking as a duplicate. In 3.3, both problems appear to be fixed. However, if you find a case that still fails, I would ask you to enter a separate bug just so the confusion around the already entered bugs is avoided (although it would still be good to reference these bugs for completeness).
OK, but couldn't these other bugs just be unmarked as duplicates? It would be simpler and there would be less bugs.
Given that both bugs are fixed, I don't see the benefit in changing any of the resolutions at this point.
