Bugzilla – Full Text Bug Listing
| Summary: | [EditorMgmt] Widget is disposed error when going back to compare editor | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Dani Megert <daniel_megert> |
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
| Status: | CLOSED DUPLICATE | QA Contact: | Remy Suen <remy.suen> |
| Severity: | major | ||
| Priority: | P3 | CC: | pwebster, tomasz.zarna |
| Version: | 3.6 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Dani Megert
Bug 146021 reports a similar issue with a less frequent scenario. It does not happen each time, does it? I've tried the steps you provided with no luck. So I started doing variations of the steps (including opening New Editor for the Compare editor) and I got the exception only once. Unfortunately I don't remember the sequence since I was clicking around like crazy. This also mean that I'm not sure if what I saw was this bug or bug 146021 (steps provided there work each time and it looks bad :/ I will give it another shot soon. btw, I tried it on I20091110-0800 and I20091117-1545. I can consistently reproduce using I20091117-1545 on WindowsXP and the steps from comment 0. The problem here is that we reuse the Compare Editor open for "current vs previous from local" and set the new input for comparison of "the two oldest". Then when "Back" is clicked Eclipse tries to restore the first editor. This is what should happen:
a) remove a navigation history entry for the first comparison ("current vs previous"). This is the culprit actual causing the exception (ie Eclipse tries to restore the first editor which is gone, reused).
b) update navigation history with the new Compare Editor ("the two oldest"). New editor input (we reuse editor part by setting new input) should mean new navigation history entry. We cannot merge[1] nav entry for the old compare editor with the new one because inputs are not equal. What we could do is to update the history in reaction to partInputChanged[2] event. However, the problem is that the old compare editor we would like to close cannot be found (using IEditorInput.equals[3]) since the input has been already replaced[4] ie in CompareEditor.setInput[5] the new input is set first and the IWorkbenchPartConstants.PROP_INPUT property change is fired later.
c) add a nav entry for the new ("the two oldest") compare editor. To achieve this when reusing Compare editor we will need to call IWorkbenchPage.reuseEditor(IReusableEditor, IEditorInput) rather than calling simply IReusableEditor.setInput(IEditorInput) as it happens right now in CompareUIPlugin.internalOpenEditor(CompareEditorInput, IWorkbenchPage, IReusableEditor, boolean). The reason for this is that CompareEditor (implementation of IReusableEditor) doesn't call navigationHistory.markEditor(IReusableEditor) when IWorkbenchPage.reuseEditor does.
I'm on it.
[1] org.eclipse.ui.internal.NavigationHistoryEntry.mergeInto(NavigationHistoryEntry)
[2] org.eclipse.ui.internal.NavigationHistory.NavigationHistory(...).new IPartListener2(){...}.partInputChanged(IWorkbenchPartReference)
[3] org.eclipse.ui.internal.NavigationHistory rev 1.47, line
[4] org.eclipse.compare.internal.CompareUIPlugin.internalOpenEditor(CompareEditorInput, IWorkbenchPage, IReusableEditor, boolean) when input!=null
[5] org.eclipse.compare.internal.CompareEditor.doSetInput(IEditorInput)
After further investigation I found bug 162939 in Platform/UI which looks very similar to this report. The UI bug is about reopening (navigating back) a closed, reused compare editor. On this report we're dealing with a situation when we navigate back to an reused but still open compare editor. The problem here is that navigation history does't know that the editor input has changed ie the history is not updated properly and it's trying to navigate to the editor with the old input. So like bug 162939 I think this is a workbench issue, but let me know if I can be of any assistance. Moving to UI for comment. I wonder if this is a more general issue with navigating between IReusableEditors with switched inputs. If someone from UI give me a tip where to start I will try to provide a test to verify it. (In reply to comment #7) > I wonder if this is a more general issue with navigating between > IReusableEditors with switched inputs. If someone from UI give me a tip where > to start I will try to provide a test to verify it. I tried doing the same thing via 'File > Save As...' and a regular text editor, changing its file input to the new file, but no success in reproducing an error so far. Is there a way to simulate switching inputs programmatically? If yes I could try to provide a unit test for that scenario. (In reply to comment #9) > Is there a way to simulate switching inputs programmatically? I believe that would be a matter of calling IWorkbenchPage's reuseEditor(IReusableEditor, IEditorInput) method. Bug 79991 may be another related bug. *** This bug has been marked as a duplicate of bug 162939 *** |