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.
Created attachment 110177 [details] screenshot Look at the screenshot, all I did was collapsing all folds and expanding them again several times. This happens a lot, I was able to reproduce it several times with php and java files. Could be related to issue #196281 but it looks a little different Product Version: NetBeans IDE Dev (Build 201108210601) Java: 1.7.0; Java HotSpot(TM) Client VM 21.0-b17 System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb)
I need a reliable testcase. I played with the feature for a while, on various sources (Java, JSP, PHP, XML) and saw the effect once, but with no reliable reproduction. Ideally, attach a source + steps to reach the erroneous state starting from file open; also try if a certain editor window size does not contribute to the problem appearing. Marking as P3, since the bug seem to happen rather infrequently.
Have you tried WinXP? I don't have problem reproducing this on them. The most detailed steps I just did to reproduce: - start dev build (201109110600) - create new PHP project - fold/unfold several times by clicking on first folding mark at line 2 and the result looks like in the first screenshot. If I repeat the same with last fold, check the new screenshot to see what happened.
Created attachment 110639 [details] second screenshot
Could you please check, in the invalid state like on screenshot #1, whether switching away from NB then back (which repaints the editor area) will display the folding correctly ?
Yes, that does help, all folds are displayed correctly
Found the root cause. The sidebar schedules repaint() when it receives FolderHiearchy event; at the same time the FoldViewFactory invalidates a region of views and schedules rebuild. SOMETIMES the repaint event is processed just before the views are recreated, so sidebar works with obsolete XY positions and view hierarchy which still records folded views. Possible solution: wait for the view hierarchy to fully update - Mila is implementing a listener for that (I will wait for it). Another possible race which should be prevented is an additional FH event in a freshly build view hierarchy (a new rebuild will be scheduled). Sidebar should not update in this case, since fold data vs. view data is not consistent at the moment.
Svato, I've just finished issue #202273. So as we've talked you could now listen on ViewHierarchyListener in o.n.m.lib2.view and check if ViewHierarchyEvent.isChangeY() returns true and if so then repaint the folding side bar. Thanks.
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/f6343d1bac5a User: sdedic@netbeans.org Log: #201270: sidebar repainted afer view hierarchy recomputes
*** Bug 201411 has been marked as a duplicate of this bug. ***
verfied NetBeans IDE Dev (Build 201109220601)
*** Bug 201921 has been marked as a duplicate of this bug. ***
*** Bug 197693 has been marked as a duplicate of this bug. ***
*** Bug 195310 has been marked as a duplicate of this bug. ***
*** Bug 116063 has been marked as a duplicate of this bug. ***