Community
Participate
Working Groups
Build ID: I20080609-1311 Steps To Reproduce: 1. Open a long file A.java. 2. Scroll to the end of the file. DO NOT CLICK IN THE SOURCE ANYWHERE. 3. Open a bunch of other files, enough that A.java gets evicted from the list of visible tabs. 4. Press the back button as many times as you need to until A.java shows up again. The source view will be positioned at the top of the file, not at the end of the file. More information: In an older version of Eclipse (that I modified for a user study), I fixed this by sticking the line page.getNavigationHistory().markLocation(page.getActiveEditor()); at the beginning of EditorManager.openEditor(). I believe that this creates another navigation entry every time you open a new tab, but IIRC the navigation entry list strips duplicates, and the performance hit was insignificant for me. (YMMV.)
I guess this is because we persist the cursor location and not (also) the current scroll position.
I would classify this as an enhancement request (i.e.: persist scroll position in addition to cursor position), but I may be missing something. Dani, what do you think?
You mean you don't want the last line and the caret to appear at the bottom right? Moving to SWT as this is provided by StyledText.
Forget the last comment, it was meant for another bug.
The problem is not the scroll position: the location isn't recorded if the editor is deactivated. I guess we should also record the position before deactivating the editor, otherwise this location gets lost as soon as that editor gets closed. Simpler steps: 1. open a file 2. put caret somewhere 3. open another file 4. close first file 5. Back ==> first file is opened with caret at position 0.
*** Bug 73224 has been marked as a duplicate of this bug. ***
*** Bug 234566 has been marked as a duplicate of this bug. ***
Dani, thanks for the investigation and explanation!
(In reply to comment #5) > Simpler steps: > 1. open a file > 2. put caret somewhere > 3. open another file > 4. close first file > 5. Back > ==> first file is opened with caret at position 0. I could not reproduce this. I also could not reproduce using the steps from bug 234566.
Created attachment 108889 [details] candidate patch This is the patch I wanted to test but couldn't because I was not able to reproduce.
Moving to M2.
>I could not reproduce this. I also could not reproduce using the steps from bug >234566. Well, you probably did too much in the "4. close first file" step ;-) I guess you first activated the editor by hitting the tab and then closed it. Instead, simply hover over the tab and hit the X to close the editor. That produces the bug for me using I20080805-1307.
(In reply to comment #12) > I guess you first activated the editor by hitting the tab and then closed it. No, I did click on the "x" without first activating the editor. There must be something else that is different between your setup and mine. Could you give the patch a try, does it fix the problem?
>There must be something else that is different between your setup and mine. Yes, I see the difference now: I can also not reproduce this on Linux but on my WindowsXP box, here my detailed steps for WindowsXP: 1. download and install I20080806-1800 into fresh directory 2. start with fresh workspace 3. create a Java project 4. import JUnit 3 or any other existing source (do not create the files as this already opens an editor) 5. in the Package Explorer double-click on any Java file 6. set caret somewhere 7. in the Package Explorer double-click on any Java file (other than in step 5) 8. click on the [X] of the other editor 9. hit the back arrow in the main toolbar ==> caret is a offset 0 NOTE: same problem when using single-click mode.
Comment on attachment 108889 [details] candidate patch Boris, I looked at the patch: the code looks good to me and it also fixes the bug on my side.
I think there are two very different problems being mixed in this bug. The first problem is that scroll location is not saved; only cursor position is saved. This is the original bug description and comment 1, comment 2. The second problem is about cursor position in case an editor has been closed (comment 5 and the rest). Those are two different issues, so I opened a bug 259808 to track the cursor issue brought by Dani in the comment 5. Bug 234566 - changed to be a duplicate for the bug 259808. On the "candidate patch": The navigation location for the "old" editor is already created whenever a "new" editor is activated. The problem found by Dani seems to be limited to editors being closed. It also does not address scroll position not being saved. Let's use this bug to follow up on the scroll position issue and bug 259808 for the caret position issue.
*** Bug 259808 has been marked as a duplicate of this bug. ***
Sorry Oleg, but you are wrong: this bug is and was about the the fact that the editor is hidden (please read comment 0 again). The scroll position bug is a known issue (bug 169838).
See also Oleg's comments and patch in bug 238202.
Oops sorry. This bug took a wrong turn in comment 3 where I assumed that the caret is set, which it isn't. So we have the following issues: - this bug: scroll position not part of the navigation history - my bug which Oleg newly reported as bug 238202 - restore bug 169838
>- my bug which Oleg newly reported as bug 238202 should read: "bug 259808"
Created attachment 121545 [details] Possible patch for JDT UI I think I found how to duplicate the problem. In my case folding was disabled for Java editors. Once I enabled folding, I can reproduce the problem with just two editors (no need to hide editor tab by opening a bunch of editors): 1. Make sure folding is enabled 2. Open long Java file, scroll to the end, do not click anywhere in the text 3. Open another Java file 4. Press back Result: the original file is opened with scroll position reset to the beginning of the file. Expected: scroll position of the open editor is preserved After some digging around I came across a place in JavaSourceViewer#setVisibleDocument(). The change in this patch fixes the scenario above for me. The patch applies to org.eclipse.jdt.ui . Dani, could you have a look at this patch? While the change seems logical to me, I am really not familiar with the JDT code around it.
It is intended that it scrolls back as the selection is marked and put into the navigation history and since scroll positions aren't part of it, it navigates back to that selection. The proposed fix is bad and does not work since it no longer correctly sets the visible document: just open a Java file and see the incorrect folding states and the screen cheese (the squares all over the document).
Yes, the "Possible patch for JDT UI" is incorrect. The patch that fixes caret position is attached to the bug 259808. The source of confusion in duplication of Dani's scenario originated from enabling Java editor folding. On the subject of scroll position (the original request in this bug): when navigation's Back/Forward is pressed: - Now: most of the time we go to the cursor position (See TextSelectionNavigationLocation#restoreLocation(). We do go back to the scroll position in some cases, such as if we have copyright header and its folding is disabled - which will change if my fix for 259808 is used.) - Proposed in this bug: we go to the scroll location After thinking about this and playing with different alterations, I believe that the current behavior is actually better than what is proposed. For me, going back to the cursor position seems to be the action I'd prefer the *majority* of the time. So, from my habits of Eclipse use, I'd rather keep the current behavior.
So after finding bug 259808 (with a potential fix attached by Oleg), I believe we are back to: (In reply to comment #2) > I would classify this as an enhancement request (i.e.: persist scroll position > in addition to cursor position)... Removing target milestone as a result.
Remy is now responsible for watching the [EditorMgmt] component area.
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.
