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.
Product Version: NetBeans IDE Dev (Build 201601130002) Java: 1.8.0_66; Java HotSpot(TM) 64-Bit Server VM 25.66-b17 Runtime: Java(TM) SE Runtime Environment 1.8.0_66-b17 System: Windows 10 version 10.0 running on amd64; Cp1252; en_CA (nb) User directory: C:\Users\Gili\AppData\Roaming\NetBeans\dev Cache directory: C:\Users\Gili\AppData\Local\NetBeans\Cache\dev 1. Set a breakpoint. 2. Start a debugging session. 3. Add a watch on a variable containing elements (e.g. List or Set) 4. Expand the variable so its elements are showing. 5. Focus the caret on (say) the 3rd element in the list. 6. Step over (F8) a single line of code. 7. (95% of the time) The variable from step 4 gets collapsed. The element you selected loses focus. Expected behavior: Variable should remain expanded. Element should retain visible selection and keyboard focus. Note that *sometimes* the variable remains expanded in step 7, but the element always loses visible selection and keyboard focus.
Clarification: If the user hits F5 and the subsequent breakpoint that is hit is able to evaluate the same variable I expect the element list to remain expanded. This holds true even if the variable in question has changed values. The IDE should attempt to retain the previous UI state as much as possible. If element 3 was previously selected and the new variable has at least 3 elements, then element 3 should still be selected. If, on the other hand, the new variable only has 2 elements then I expect the closest element (element 2) to be selected ... and so on. The only time I expect the elements to get collapsed is if the variable doesn't exist in the current context. I also expect the following to work: Breakpoint 1 hit: Variable "List", element 3 is selected. Breakpoint 2 hit: Variable "List" doesn't exist in debugging context so the value should be collapsed. Breakpoint 3 hit: Variable "List" exists in debugging context, so the IDE should attempt to restore the same state as breakpoint 1 (expand the list, and select element 3). I hope this clarifies what I mean: the IDE is expected to retain the user preferences for as long as possible. Justification: Very often I am debugging a variable's state across multiple breakpoints. The fact that the variable view keeps on collapsing hampers my productivity. I end up having to expand the view hundreds of times per hour.