Community
Participate
Working Groups
Created attachment 153473 [details] test project N20091130-2000 - import attached project - select the three .java files in the source folder - context menu > Compare With > Each Other - select JV_1_100.java as common ancestor - click the first 'Copy Current Change from Right to Left' button in the gutter between the two text viewers => change is correctly copied (loss of context is bug 287421) - click the next 'Copy Current Change from Right to Left' button => left side is garbled: import org.eclipse.ui.IWorkbenchPage; import org.eclipse.ui.IWorimport org.eclipse.ui.IWorkbenchSite; kbenchPart; import org.eclipse.ui.IWorkbenchPartSite; Same problem if I use the buttons from the toolbar inside the compare editor. I originally got this when I tried to merge a conflict in the file from CVS. When I do the same with the .txt files in the 'comp' folder, then it works fine.
I've been having problems myself yesterday and today too.
Caused by bad fix for bug 291695.
Created attachment 153513 [details] propose patch This patch might fix the issue without the need to revert bug 291695. The previous design was brittle as it implicitly assumed that the documents of a TextMergeViewer would initially be set via ContributorInfo.setDocument(..). In reality, also TextMergeViewer.configureSourceViewer(..) may set the document (via a completely remote call chain). If setDocument(..) finds the same document already installed, it misses to connect a position updater. The patch fixes this by adding initialization of position updaters to configureSourceViewer(..). This fixes the immediate issue of this bug, but I haven't done excessive tests.
Thanks a lot for the patch Stephan. So far I haven't any side effects caused by your patch, except that it fixes the bug :). I have filed bug 296694 but it's not related to the compare editor itself, I'm just trying to cover more cases than we did on bug 291695.
Found a scenario when the patch causes an exception: do "Compare With > Latest from HEAD" for a modified, plain text file. Here is the full stack: org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.NullPointerException) at org.eclipse.swt.SWT.error(SWT.java:4068) at org.eclipse.swt.SWT.error(SWT.java:3983) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:137) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3906) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3527) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2407) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2371) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2220) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:367) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:611) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:566) at org.eclipse.equinox.launcher.Main.run(Main.java:1363) at org.eclipse.equinox.launcher.Main.main(Main.java:1339) Caused by: java.lang.NullPointerException at org.eclipse.compare.contentmergeviewer.TextMergeViewer$ContributorInfo.connectPositionUpdater(TextMergeViewer.java:780) at org.eclipse.compare.contentmergeviewer.TextMergeViewer.configureSourceViewer(TextMergeViewer.java:2888) at org.eclipse.compare.contentmergeviewer.TextMergeViewer.updateContent(TextMergeViewer.java:2828) at org.eclipse.compare.contentmergeviewer.ContentMergeViewer.internalRefresh(ContentMergeViewer.java:783) at org.eclipse.compare.contentmergeviewer.ContentMergeViewer.inputChanged(ContentMergeViewer.java:683) at org.eclipse.jface.viewers.ContentViewer.setInput(ContentViewer.java:274) at org.eclipse.compare.CompareViewerSwitchingPane.setInput(CompareViewerSwitchingPane.java:270) at org.eclipse.compare.internal.CompareContentViewerSwitchingPane.setInput(CompareContentViewerSwitchingPane.java:132) at org.eclipse.compare.CompareEditorInput.internalSetContentPaneInput(CompareEditorInput.java:834) at org.eclipse.compare.CompareEditorInput.access$7(CompareEditorInput.java:832) at org.eclipse.compare.CompareEditorInput$10.run(CompareEditorInput.java:772) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.compare.CompareEditorInput.feed1(CompareEditorInput.java:766) at org.eclipse.compare.CompareEditorInput.feedInput(CompareEditorInput.java:744) at org.eclipse.compare.CompareEditorInput.createContents(CompareEditorInput.java:555) at org.eclipse.compare.internal.CompareEditor.createCompareControl(CompareEditor.java:454) at org.eclipse.compare.internal.CompareEditor.access$6(CompareEditor.java:421) at org.eclipse.compare.internal.CompareEditor$3.run(CompareEditor.java:377) at org.eclipse.ui.internal.UILockListener.doPendingWork(UILockListener.java:155) at org.eclipse.ui.internal.UISynchronizer$3.run(UISynchronizer.java:158) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134) ... 23 more
Created attachment 153643 [details] patch 2 (In reply to comment #5) I should have considered this in the first place: document can indeed be null after configureTextViewer - perhaps only Java editors do configure the document already at this time? The updated patch catches that case. This is safe because then if document is still null the position updaters will be installed the next time setDocument will be called.
(In reply to comment #6) > I should have considered this in the first place: document can indeed > be null after configureTextViewer - perhaps only Java editors do > configure the document already at this time? That is correct. Java compare is the only editor (so far) that leverages the new API introduced in bug 169386.
Patch applied to HEAD. All credit goes to Stephan, thanks again! The fix will be available in builds >=I20091207-1300.
Verified in I20091208-0100, however there are still open bugs that refer to comparing elements (bug 297316, bug 293674).
