This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I have noticed in recent builds (incl. 5.0? not sure) that the editor no longer scrolls to the caret when you open a Java file (at least) at a specific point. E.g. when doing Find Usages and using F12 to jump to usages in previously unopened files, the file opens and the caret is set correctly but it is off-screen. If you press any arrow key (for example) then the view suddenly scrolls to the right place. I run JDK 6 on Linux and have the Java editor set to fold imports and initial comments.
Reproduced. I'll attempt to fix it.
This still happens to me frequently, by the way.
Raising to P2. This is really annoying behaviour and it leads users to think that more functionality is broken, as it appears in refactoring, debugger, ...
Said to also exist in 5.5?
Yes, thanks, I didn't notice it's filed against 6.0. I'm experiencing the same in 5.5. Would be good to have a fix this in 5.5.1.
*** Issue 72699 has been marked as a duplicate of this issue. ***
*** Issue 76619 has been marked as a duplicate of this issue. ***
I've found the problem - the modelToView() returns null at BaseCaret:293 so the caret bounds cannot be determined and the view does not scroll. I need to find out why this happens.
I further tracked the problem and at the time of calling setDot() from SimpleRefactoringElementImpl the editor still has zero bounds i.e. getBounds() returns empty rectangle. In such case BasicTextUI.getVisibleEditorRect() returns null and the code does not inspect view's modelToView() at all. I have also checked whether the DrawEngineDocView does not return zero preferred span at the begining but the View.getPreferredSpan() gets called later than this particular modelToView(). I have also tried to reorder the call to getTopComponent(panes[0]).requestActive(); to be before the setting of the caret position but that did not help either. I have workarounded the problem by posting the setDot() call into SwingUtilities.invokeLater() in SimpleRefactoringElementImpl which helps. Finally I have attempted a fix in caret that checks in paint() whether the caret's offset was set but the caret bounds are still null and if so it recomputes the bounds and scrolls the component if necessary. Although it's a bit ugly to call things like scrolling from the paint() but it seems to work fine. So I will leave this fix for now and if it would cause problems I will roll it back and apply the SwingUtilities.invokeLater() fix. Checking in BaseCaret.java; /cvs/editor/libsrc/org/netbeans/editor/BaseCaret.java,v <-- BaseCaret.java new revision: 1.128; previous revision: 1.127
reproducible in netbeans-1915
Tim, could you please mention the steps how to reproduce? Is it still clicking Enter from Find Usages window or anything else? Thanks.
I'm seeing this when using Goto-Source (Alt-O) or when during debugging when using "Step Into" (F7)
I have searched for "todo" in my sources and jumped to the found places from the results window with double click. Important is probably that I have the options "collapse initial comment" and "collapse imports" switched on.
Also still not working well for me in 070202 under JDK 7 on Linux. I also fold initial comments and imports. When I search for usages of org.openide.util.Union2, two hits are in core/bootstrap/src/org/netbeans/Module.java, in the import and in one real usage. If I double-click the second usage, opening the file, the file opens and momentarily displays the usage, but almost immediately the viewport switches to lines 542-578. Pressing Right immediately switches the viewport to 508-544, which is correct (the usage is on line 526). Lines 1-18 are the initial comment and lines 22-39 are imports. That makes 34 fewer physical lines displayed when folding, which is exactly the amount by which the viewport is initially wrong. So clearly you need to update the viewport to scroll to the caret *after* applying initial folds, or else make code folding correct the viewport position.
*** Issue 90877 has been marked as a duplicate of this issue. ***
I've made another fix to retain the relative position of the caret against the visible view after fold hierarchy update. Hopefully this should fix the remaining problems related to this issue: Checking in libsrc/org/netbeans/editor/BaseCaret.java; /cvs/editor/libsrc/org/netbeans/editor/BaseCaret.java,v <-- BaseCaret.java new revision: 1.129; previous revision: 1.128
*** Issue 87172 has been marked as a duplicate of this issue. ***
reproducible in 070401 I searched for "StringBuffer" in my source files and double clicked in the "Search Results" window on a line. Linux, JDK 1.6.0_01
*** Issue 117564 has been marked as a duplicate of this issue. ***
Should work now after this and Mila's previous fixes in BaseCaret. Checking in BaseCaret.java; /cvs/editor/libsrc/org/netbeans/editor/BaseCaret.java,v <-- BaseCaret.java new revision: 1.141; previous revision: 1.140 done
This seems to have resurfaced again in recent dev builds.
http://hg.netbeans.org/main/rev/8bcee4facc8b
Integrated into 'main-golden', will be available in build *200810140201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/8bcee4facc8b User: Vita Stejskal <vstejskal@netbeans.org> Log: #70915 - fire fold hierarchy events to the listeners in the same order as they registered