Community
Participate
Working Groups
Build Identifier: 20120614-1722 when I double click on a error and the file opens up with the error at the caret postion, when I scroll using the mouse wheel, the view position jumps to the top of the file. Reproducible: Always Steps to Reproduce: 1. open a file using a hyperlinked position (error, search result) 2. scroll up with the scroll wheel on your mouse 3. see the position jump to the top of the document
Created attachment 219044 [details] Quicktime movie showing the behavior described This video opens a file using a double click on an error in the task view. Then I use the scroll wheel to scroll up. The view position jumps to the top of the document.
I got the same problem. Whenever I do an action that opens up a new editor (like a Java editor when using the problem view, open declaration, call hierarchy, etc.) and places the caret somewhere in the file, the scroll bar does not "follow". If the caret is in the middle of the file, then the scroll bar should be in the middle of its area too, but it's not the case; it's always at the top. So when I scroll using the mouse wheel or the scroll bar, the view in the editor jumps to the beginning of the file. However, if the editor was already open and the action merely brings the editor to the top, then everything works fine. I'm using Eclipse 4.2 under Ubuntu 11.04.
Created attachment 219437 [details] Scroll bar at the top but caret in the middle of the file A screenshot that shows the bug: the caret is at the line 107 but the scroll bar is at the top of its area.
Same problem here on Mac OS X (10.7.4), Eclipse (Juno 20120614-1722)
I cannot reproduce this on Mac OS X 10.6.8, but it could very well be specific to Lion or Ubuntu with their non-persistent scroll bars. Maybe it's also fallout from bug 375576 and disappears when that bug is fixed.
In fact, this should be closed as a duplicate of 383820, which is exactly the behaviour I'm experiencing. And that bug has been marked as a duplicate of 375576 by Dani Megert, so you're probably right.
Reproduced with 4.2 on Mac OS X 10.7.4. Does not happen with 3.8. *** This bug has been marked as a duplicate of bug 375576 ***