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.
steps to reproduce: - have code folding enabled - turn on initial comment collapsed by default - now go to any declaration (ctrl+click) so that the new file is opened (and it better be a long file) Now sometimes it opens at the correct position and sometimes not (first it opens at the correct position and the immediately scrolls somewhere). It is not reproduced with the default collapsing turned off.
Please check whether you have some 'custom folds' in the text. Either generated by form editor, or entered manually (// <editor-fold defaultstate="collapsed" ...)
no I do not have any custom folds, just now I've tried to go to CPP class (IndexingSupportTest.java) from parsing.api module with enabled collapse initial comment and imports. CPP class is at the bottom of the file and it opened correctly but then immediately scrolled a couple sceens up.
OK, I put a few debugging messages into BaseCaret, into updateCaret() method and the surroudnings. What is interesting is this: // caret position is changing, apparently because of several collapsed folds, which wever introduced CaretBounds: java.awt.Rectangle[x=120,y=97954,width=8,height=17], old = java.awt.Rectangle[x=120,y=99331,width=8,height=17] // the visible rect contains the 'old' caretBounds pos, but does not contain the new one visible rect: java.awt.Rectangle[x=0,y=98965,width=1207,height=664] scrollViewToCarat = false, updateAFH= false // will attempt to scroll the view to show the caret Fixing caret visual position // note the scrollBounds rectangle contains the new caret position, AND, that the scrolled-to window is still within the bounds doScroll = true, scrollBounds = java.awt.Rectangle[x=120,y=97588,width=8,height=664], bounds = java.awt.Rectangle[x=0,y=-98965,width=1207,height=99637] // ERROR: see the Y coordinate of the result of the scroll. The scrollTo rectangle is completely outside the current region ! Visible rect after scrolled: java.awt.Rectangle[x=0,y=96219,width=1207,height=664] CaretBounds: java.awt.Rectangle[x=120,y=97954,width=8,height=17], old = java.awt.Rectangle[x=120,y=97954,width=8,height=17] visible rect: java.awt.Rectangle[x=0,y=96219,width=1207,height=664] scrollViewToCarat = false, updateAFH= false doScroll = false, scrollBounds = java.awt.Rectangle[x=120,y=97954,width=8,height=17] Once the caret becomes invisible (outside of scrolling region), the visual position is not updated when a fold gets collapsed - the same situation as if the user scrolled apart from caret by e.g. mousewheeel, then collapsed some fold: the viewport should not move.
Changeset: 72f4107ac63d Author: Svata Dedic <sdedic@netbeans.org> Date: 2012-10-22 15:37 Message: Again simplified threading of foldHierarchyChanged. Scroll position is adjusted just once in updateCaret.
I'm going to push an attempt to fix the issue. There is however still an issue with Component.scrollRectToVisible() failing; repeated call seems to succeed - I am not proud of that code at all, but seems somehow to work (I noted in the code that it is a hack). Please try to observe the behaviour for a few days during daily work.
Great, thanks! I'll try it as soon as it appears in the nightly build.
Integrated into 'main-golden', will be available in build *201210250001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/72f4107ac63d User: Svata Dedic <sdedic@netbeans.org> Log: Issue #219580 - Incorrect position in the file after go to when collapse by default enabled: fixed Again simplified threading of foldHierarchyChanged. Scroll position is adjusted just once in updateCaret.
I'm using NetBeans IDE Dev (Build 201301120001) and it is better now, but still sometimes after a new file is opened it scrolls somewhere so that the requested position is not even visible.
*** Bug 221784 has been marked as a duplicate of this bug. ***
Now using Dev Build 201305212300, here it is reproduced every time, and this bug makes collapse by default functionality really unusable. Please consider raising the priority. Thanks!
(In reply to comment #10) > Now using Dev Build 201305212300, here it is reproduced every time, and this > bug makes collapse by default functionality really unusable. Please consider > raising the priority. Thanks! What file type do you work with ? Could you attach a sample file and describe how you open it (use navigator, goto symbol, ...) ? I'll try to produce the issue on the exact build.
I'm working with many netbeans modules, having initial comment and java imports collapsed by default. Scenario that is reproduced all the time now: - open FindUsagesOpenAction from refactoring.api - set a breakpoint at the line 77 - close the file - open breakpoints view - double click on a breakpoint to open the file In 70% of cases it opens on the correct position and immediately collapse initial comment and imports and scrolls to the incorrect position. I can close the file and reopen it again with the same incorrect position.
Still no luck. I tried several times, in either dev build or the mentioned 2013-05-21, with background parsing (= slower appearance of folds) or without. I've added some more logging in http://hg.netbeans.org/jet-main/rev/4ef31ebf55b4. Please run with -J-Dorg.netbeans.editor.BaseCaret.level=400 -J-Dorg.netbeans.modules.editor.fold.ui.FoldingEditorSupport.level=400 and attach the output here + detailed scenario
Integrated into 'main-golden', will be available in build *201306050626* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/4ef31ebf55b4 User: Svata Dedic <sdedic@netbeans.org> Log: #219580: added more logging
Created attachment 135638 [details] log with flags With build NetBeans IDE Dev (Build 201306102301) everything is the same, attached is my log file (with the flags).
It still happens all the time, raising the priority. Do you need some extra information to fix it? Product Version: NetBeans IDE Dev (Build 201307012300) Java: 1.7.0_21; Java HotSpot(TM) Client VM 23.21-b01 Runtime: Java(TM) SE Runtime Environment 1.7.0_21-b11 System: SunOS version 5.11 running on x86; UTF-8; en_US (nb)
I have collapse by default initial comment and java imports. When I click on Breakpoint FindUsagesOpenAction.java:77, it jumps correctly to 77 line, but view is on top and I do not see line 77.
My version and metal laf: Product Version: NetBeans IDE Dev (Build 201307312300) Java: 1.7.0_25; Java HotSpot(TM) 64-Bit Server VM 23.25-b01 Runtime: Java(TM) SE Runtime Environment 1.7.0_25-b15 System: Linux version 3.0.0-32-generic running on amd64; UTF-8; en_US (nb) User directory: /home/mito/nb/jet-main-userdir Cache directory: /home/mito/nb/jet-main-userdir/var/cache
I cannot reproduce it on gtk. I find it happens only on external monitor on metal, not on my notebook monitor.
what's your dual monitor setup - relative positions of the screens ?
Marvellous ... it seems that the IDE window height must be "right" to trigger the defect. If I maximized the window, the editor scrolled OK; if the window is approx 2/3 of the 1024px screen height, the editor scrolled to 1st line while the caret remained on line #77
For some reason, can be reproduced if window size = 1280 x 820
I also have dual monitor configuration, two monitors 1920x1200, and the IDE is maximized on the second screen
It seems that something interferes with BaseCaret repositioning the viewport. I've put logs into (overriden) Viewport.setViewLocation, and after setting (correct) y-offset to display caret, the view suddenly came with y-coordinate reset to 0. I would like someone (Egor, Mito ?) to check the following scenario. I believe there's a subtle bug in JDK which causes the scroll to zero position if - for whatever reason - the scrolled view is not valid at the time scrollRectToVisible is called. It seems that JComponent.scrollRectToVisible recalculates the rectangle to parent coordinate system prior to calling parent.scrollRectToVisible(). That means the rectangle is offset by CURRENT Component's x,y. The JViewport.scrollRectToVisible validates the view if it is !isValid(), which causes re-layouting the viewport and possibly a call to JComponent.setViewPosition() from the layout manager. That means the x,y of the view changes. From this point on, the point previously translated into JViewport coordinates no longer correspond to the original content position as the view was relayouted and shifted. Subsequently, the JViewport calculates the desired position as negative and resets Y position of the view to 0. Since I am able to reproduce the bug only occasionaly, please try to apply the attached diff & test, please.
Created attachment 139331 [details] Potential fix
I can not reproduce the problem after the patch is applied
After patch, I cannot reproduce it either.
Fixed in http://hg.netbeans.org/jet-main/rev/463d3fe41c1c
Integrated into 'main-silver', will be available in build *201309010001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/463d3fe41c1c User: Svata Dedic <sdedic@netbeans.org> Log: #219580: validate component to prevent defect in scrollTo