Community
Participate
Working Groups
STEPS: 1. In a Java editor, hold the Ctrl modifier while left-clicking an identifier (which will appear as a hyperlink) to navigate to a new location in the text editor. 2. Press Alt+Left to "browse back" Expected: * The editor returns to the location where the hyperlink was clicked Actual: * The editor returns to a previous location in the editing history. WORKAROUND: * After pressing Alt+Left, pressing Alt+Right can be used to return to the desired location. Note however, pressing Alt+Right a second time does NOT continue browsing forward to the most recent point viewed, as would be expected. It seems the location of the hyperlink target is not added to the browse history either. Not sure if this first appeared in Juno or Kepler for me, sorry.
I cannot reproduce this using R4.3 [1]. If you can still reproduce with said build, then please provide exact steps. Also, you might just see bug 344058. [1] http://download.eclipse.org/eclipse/downloads/drops4/R-4.3-201306052000/
More exact steps: 1. From the body of any Java method, insert: java.util.ArrayList al; 2. Ctrl+Click on ArrayList 3. Ctrl+Click on List 4. Ctrl+Click on Collection 5. Press Alt+Left In my Eclipse, step five lands me at ArrayList.java Something seems to be stopping "Collection" from going onto the history stack. The toolbar button's dropdown shows: * ArrayList * MyClass If instead of step 5, I press Ctrl+Shift+Down (to jump to a point within Collection) everything corrects itself. Both points within Collection are now in the history stack, and the toolbar button's dropdown shows: * Collection * List * ArrayList * MyClass I'm currently using the official Kepler "Release Build id: 20130614-0229" (Classic). Are you sure you need me to retest with an older version? It doesn't seem related to bug 344058, this happens to me every time. If it is possibly some plugin conflict / interaction, what other things could I check for, or what information should I post?
(In reply to comment #2) > More exact steps: > 1. From the body of any Java method, insert: > java.util.ArrayList al; > 2. Ctrl+Click on ArrayList > 3. Ctrl+Click on List > 4. Ctrl+Click on Collection > 5. Press Alt+Left I do exactly those steps except: 0a. install http://download.eclipse.org/eclipse/downloads/drops4/R-4.3-201306052000/ 0b. start with a new workspace using JRE 7 replace 1. with: paste: "java.util.ArrayList al;" into 'Package Explorer' Step 5 brings me back to Collection. > I'm currently using the official Kepler "Release Build id: 20130614-0229" > (Classic). Are you sure you need me to retest with an older version? The version I gave you is the/our official SDK build without any additional stuff. > If it is possibly some plugin conflict / interaction, what other things > could I check for, or what information should I post? It's possible that a plug-in causes this. E.g. Mylyn tries to hide things which are not related to the current task.
(In reply to comment #3) > Step 5 brings me back to Collection. Correction: It brings me from Collection to List.
More insight from playing around: After restarting eclipse, or switching to a clean workspace, it starts out working. At some point later, it transitions from the working state to the broken state. Playing with the clean SDK version from comment 1, I think I've found a trigger that is successful at breaking it: switching perspective. So a complete sequence would be: Setup: 0a: Install clean Eclipse SDK (64 bit Windows) 0b: Start with a new workspace using JRE 7 0c: Paste: "java.util.ArrayList al;" into 'Package Explorer' 0d: Ctrl+Click ArrayList, attach source (from JDK 7 u 25) 0e: Restart Eclipse Reproduce: 1. Open Snippet.java 2. Ctrl+Click on ArrayList 3. Ctrl+Click on List 4. Ctrl+Click on Collection (observe history is correct) 5. Switch perspective from Java -> Debug 6. Open Snippet.java 7. Ctrl+Click on ArrayList 8. Ctrl+Click on List 9. Ctrl+Click on Collection (observe history is wrong) 10. Press Alt+Left
> 5. Switch perspective from Java -> Debug This is the crucial step. With that I can also reproduce the problem. Works fine in 3.x.
This also works in 4.2.x but no longer in 4.3 and 4.4 (I20130805-2000). Simpler steps without involving JDT: 1. start new workspace 2. create general project 'P' 3. create file named "A" (leave editor open) 4. create file named "B" (leave editor open) 5. create file named "C" (leave editor open) ==> history is OK 6. open 'Resource' perspective 7. click on editor tab 'A' 8. click on editor tab 'B' ==> history is broken: wants to go back to 'C' instead of 'A' 9. click on editor tab 'C' ==> history is broken: wants to go back to 'A' instead of 'B'
*** Bug 414978 has been marked as a duplicate of this bug. ***
*** Bug 414977 has been marked as a duplicate of this bug. ***
Having the same problem with CDT - editing C files, but perspective is NOT switched - even Editors are not switched, all done in "C/C++" perspecitve with default C editor. Currently seeking a way to reproduce error - it seems to appear and disappear in the middle of the work
Sorry, forgot to add Eclipse CDT 2.0.0.20130613-0530, platform 4.3.0.I20130605-2000
Please, why don't you try to fix that unsupportable bug into a patch or at least E4.3.1 instead of E4.4 ?
If we can find the cause then something like this (loss of functionality) would likely be a candidate for back porting to 4.3.2 (SR2).
For everyone else interested in this: I just saw in the recent commits that Eric and Dani have done some work on it this week. --> bug 416902 Thanks a lot to both of you!
(In reply to Michael Heß from comment #14) > For everyone else interested in this: I just saw in the recent commits that > Eric and Dani have done some work on it this week. --> bug 416902 > > Thanks a lot to both of you! Unfortunately it does not fix this bug here.
I could not reproduce this bug with Eclipse 4.3.1. That is with Build Id: M20130911-1000 Can anybody confirm this?
I've since moved on to Eclipse 4.4M3 (I20131030-2000, Java 8ea, 32b) and I am happy to report that I don't see the issue there.
(In reply to Luke Usherwood from comment #17) > I've since moved on to Eclipse 4.4M3 (I20131030-2000, Java 8ea, 32b) and I > am happy to report that I don't see the issue there. Using the steps from comment 7 shows that the issue is still there in 4.4 M5.
> Using the steps from comment 7 shows that the issue is still there in 4.4 M5. Confirmed here too (4.4M3)
Still seeing this in Oxygen... see comments I posted on https://bugs.eclipse.org/bugs/show_bug.cgi?id=445021
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This is still relevant. Also see the issue I linked in my earlier comment. It has more information about why this happens. It's a rather weird timing issue that looks suspiciously like a hack to fix some other problem.
