Community
Participate
Working Groups
[I20061024-1200] Seems to be related to reusing editors. Steps: 0. Set your editor preferences to: - Close editors automatically - Number of opened editors before closing: 1 1. Open SWT's Item.java or Item.class 2. select the getText() method 3. Hit Ctrl-T to display the method hierarchy 4. Pick TableItem's implementation of getText() 5. Hit Alt-Left Expected: I get back to Item.getText() Actual: The cursor is put at the top of TableItem, I have to hit Alt-Left again to go back to Item.getText().
Boris, the general navigation stuff is in Platform UI. Since you sent this to us: did you verify that this is not a Platform UI bug?
Created attachment 54718 [details] patch (In reply to comment #1) > Boris, the general navigation stuff is in Platform UI. Since you sent this to > us: did you verify that this is not a Platform UI bug? No I didn't. If I knew how this worked I would have. My thinking was that it is JDT or text because I am seeing a superfluous location in my history. Anyway, I looked at our code and found a suspicious asyncExec. The attached patch solves my problem, but I am not sure about potential regressions. Assuming you know how the navigation history works, could you have a look at the patch and comment whether this appears safe? (Perhaps we should try get rid of the asyncExec altogether? It feels like a hack that can produce unpredictable behaviour.)
I have released my patch for now since it seems to fix a bug and I don't see how it could introduce new bugs.
This seems to fix the bug. Note that there's bug 154431 again but probably unrelated to this one.
Marking as fixed.
This is happening again.
Moving to JDT for comment - in JavaEditor.setSelection(), I see two calls of INavigationHistory.markLocation(). The relevant stack trace (package names omitted) of the first one looks like this: at NavigationHistory.markLocation(NavigationHistory.java:212) at AbstractTextEditor.markInNavigationHistory(AbstractTextEditor.java:5526) at JavaEditor.setSelection(JavaEditor.java:2078) at JavaEditor.setSelection(JavaEditor.java:2207) at EditorUtility.revealInEditor(EditorUtility.java:183) at JavaUI.openInEditor(JavaUI.java:672) at OpenTypeAction.run(OpenTypeAction.java:65) and for the second one: at NavigationHistory.markLocation(NavigationHistory.java:212) at AbstractTextEditor.markInNavigationHistory(AbstractTextEditor.java:5526) at JavaEditor.setSelection(JavaEditor.java:2179) at JavaEditor.setSelection(JavaEditor.java:2207) at EditorUtility.revealInEditor(EditorUtility.java:183) at JavaUI.openInEditor(JavaUI.java:672) at OpenTypeAction.run(OpenTypeAction.java:65) So setSelection() appears to call AbstractTextEditor.markInNavigationHistory two times. The first call (line 2078) happens because textSelection.getOffset() returns 81, not 0 as one could expect. To reproduce, set the maximum number of editor tabs to one and then use Ctrl-Shift-T twice, first on AbstractTreeViewer and then on TreeViewer.
This only happens on editor reuse otherwise it works just fine. I have to figure out why reuse makes a difference. We might get different (more?) selection change events.
Created attachment 57913 [details] Fix The problem is that the reuseEditor code calls the markNavigationHistory in the same chain as the input is set while during normal open this is posted async to the UI thread. The attached patch fixes this.
Thanks Dani! Released >20060131.
In I20070206-0010 PW
