Community
Participate
Working Groups
Build Identifier: eclipse SDK 3.6.0 M7 Build id: I20100426-0852 When double click on a tree item that is adaptable to IResource class, eclipse launches the editor for the file that was returned by the tree item via the call ((IAdaptable)treeItem).getAdapter(IResource.class) See debug session in the attachment. This is a regression bug. Reproducible: Always Steps to Reproduce: 1. Open a logical model tree that contains some tree items that are adaptable to IResource (such as sub model element). 2. double click on the tree item that is adaptable to IResource class Result: The eclipse's OpenActionProvider launches the editor for the file that was returned by the tree item via the call ((IAdaptable)treeItem).getAdapter(IResource.class)
Created attachment 168227 [details] Debug session
Just when I thought I was done with RC1. This was caused by a fix in M7 to call the OpenFileAction.selectionChanged() to address another bug 288997. Investigating how to deal with this now.
Created attachment 168233 [details] Patch for RC1 This backs out the change made by the fix to bug 288997
Created attachment 168235 [details] plugin to test with Duc, can you test this one?
(In reply to comment #0) > Result: > The eclipse's OpenActionProvider launches the editor for the file that was > returned by the tree item via the call > ((IAdaptable)treeItem).getAdapter(IResource.class) Why is this wrong? What did you expect to happen (or what did happen in 3.5) upon a double-click?
(In reply to comment #5) > Why is this wrong? What did you expect to happen (or what did happen in 3.5) > upon a double-click? So the issue here as far as I understand it only happens when the Java content is not enabled, because the Java content provider overrides the resources one. So when the OpenActionProvider is enabled, it controls setting the selection for the workbench's OpenFileAction. Previously, it would call the OpenFileAction to set the selection state only if it had a single file selected, so that if you had something in the navigator that adapted to file, the OpenFileAction's selection state would never see it. WIth the fix it would set the selection state using the workbench code to calculate this which would include anything that could be adapted to a file. Later, the viewer's open mechanism would call this action handler and it would open whatever it thought was selected (or nothing if nothing was selected). So if you had an object in the navigator that could be adapted to a file, the OpenFileAction would always be called (probably first) to open it, so then when the real action provided what wanted to open this was called later, it would be too late since the editor was already opened. The original fix to bug 288997 needs to be more sophisticated to handle this case.
+1 for reverting, given where we are in the cycle that's the best we can do. Can you please reopen bug 288997 to make sure it doesn't fall through the cracks? Thanks.
We have our own handler to hndle the double-click. The tree item adapts to multiple things and IFile is just one of them. When double-click happens we open a specialized editor that handles portion ofthe file. But because of the new behavior the main editor for the entire file gets opened instead.
Released to HEAD 3.6RC1
Yes. The test fix is good. I tested the attached test plugin (org.eclipse.ui.navigator.resources) and it resolved this wrong editor open problem. Thanks.
(In reply to comment #10) > Yes. The test fix is good. > I tested the attached test plugin (org.eclipse.ui.navigator.resources) and it > resolved this wrong editor open problem. > Thanks. Thanks for your good initial debugging on this and your quick response on the testing; hopefully there won't be any further regressions you find.
Duc, can you verify this works in the RC1 build?
Yes. The problem is fixed in the eclipse 3.6 RC1 build.
