Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 Build Identifier: 20090920-1017 When you hit a breakpoint, the Debug view changes its focus, but not always to the callstack that was actually hit. If another suspended callstack exists farther up in the view, then that is the one that will get focus. Reproducible: Always Steps to Reproduce: 1. Make two Java projects "j1" and "j2". 2. Make a class "j1" in the first project, "j2" in the second. 3. Give each one a main() function that has a System.out.println("hi") line. 4. Set breakpoints on both System.out.println() lines. 5. Open j1.java, and click Debug. You will hit the breakpoint in j1.main(), and the Debug view will change its selection so that j1.main() is selected. 6. Open j2.java, and click Debug. Actual result: The contents of the Debug view update correctly so that it now shows both j1 and j2; however, j1.main() is still the current selection in that view. Expected result: Since the most recent debug event to occur was hitting a breakpoint in j2.main(), I would expect the Debug view to set its selection to j2.main().
This is the designed/intended behavior. Basically, if the user if focused on a suspended thread, we don't want to take focus away from it automatically - they might be doing something important. Each thread that suspends is queued as the "next important focus point", so when the user resumes the first thread, selection will move to the next suspended thread.
If thread groups are enabled and the breakpoint is in a thread that is in a 'collapsed' group then you can wind up with no stack frame having focus and you have to go opening each group to find the thread.
Working as expected. Please open a separate bug for JDT for the threads-group use case if needed.
