Community
Participate
Working Groups
Build Identifier: 20100917-0705 When in the XML editor I press Alt+Shift+W (Show In) and select Package Explorer I always get the message: "Cannot reveal the selected element. Do you want to remove some filters to reveal the element?" Choosing "Yes" makes the file properly selected in the Package Explorer but then it turns the view filters off, while the filters don't really hide the file. Placing the cursor at the end of the XML file and issuing the same makes the file selected in the Package Explorer without giving the "cannot reveal" dialog. "Show In -> Navigator" works as expected no matter where the insertion point is currently in the editor. "Show In -> Project Explorer" doesn't display "cannot reveal" dialog, but doesn't select the file in the view, unless I position the caret at the end of the editor. Reproducible: Always Steps to Reproduce: 1. Open an XML file in the "Java" perspective; 2. Position the insertion point in the middle of the file; 3. Choose Navigate -> Show In -> Package Explorer.
If we look into CommonNavigator.getSelection(ShowInContext context) function, there is a condition if (selection != null && !selection.isEmpty() && selection instanceof IStructuredSelection) return (IStructuredSelection)selection; Whenever cursor is not at end position selection is not empty, hence we return this selection.This selection for example in case of html could be body or head node.This class is not able to make out file path from this information, hence we don't see it highlighted. If cursor is at end position, selection is empty and we return FileEditorInput in next line, and it shown properly. I am not sure how we can fix this since we cannot change the way we provide selection and CommonNavigator class is not provided by us.
So you the problem lies in the Package/Project Explorer views and not in the XML editor? Note the Navigator view works just fine - what's the difference which makes it work with it and not with the other views?
*** Bug 334776 has been marked as a duplicate of this bug. ***
This was fixed by having our DOM adapt to IResource through Bug 208636.
