Community
Participate
Working Groups
M1: The JDT debugger may seize focus from the JDT editor. After a debugging session had hit some breakpoint, I reverted to development and edited in the debugger perspective. After a while I switched to the Java perspective and continued editing. During this editing I caused an add com.google.guava to required bundles quick fix to be executed. I continued editing, but lost control as the debug perspective took over. It would appear that the MANIFEST.MF save for the quick fix caused a sufficiently large rebuild for the debugger to think it was in use again and so it grabbed focus, set the prevailing input line and in doing so corrupts my editing position.
Somewhat simpler... Run a JUnit Test under the debugger so that it will eventually stop at a breakpoint. Continue using Eclipse, perhaps typing in some editor. When the breakpoint is hit, the focus is stolen and some of the typing probably corrupts the changed context. --- The debugger breakpoint hit should not grab focus. It may change perspective but the editor should be equivalently useable in the new perspective. In a similar way to Windows (only sometimes) flashing a toolbar tool that needs attention, Eclipse could flash the page tab/perspective icon that would like to receive focus (at the user's convenience). Or flash something on the status bar.
About to raise a duplicate: After stopping at a breakpoint, the debugger perspective editor view displays the source code and allows it to be edited. Good. But, once the user starts to edit so that the editor is dirty, the focus should remain with the editor and away from the debugger to prevent the incremental rebuild repositioning the cursor at the start of the function containing the breakpoint and therefore corrupting the user's continuing editing actions. The debugger should not regain focus until a 'step' button is pressed or a stack trace context is clicked. But not when e.g. a breakpoint is toggled; breakpoints should use the visible (dirty) editor state even though it is out-of-synch with the stack element line positions. (This particular report was finally triggered by corruption of a sequence of four tab insertion edits at normal typing speed, two inserted as required, two went elsewhere!)
If someone has bandwidth to work on it.
Bug 576059 seems like a duplicate. While searching for this bug to add a variant phenomenon, the Bugzilla search suggests at least 10 open bugs in regards to debugger focus, and many more fixed. This strongly suggests that there is a fundamental design issue that needs to be addressed in regard to debugger focus policy. Many reports and corrupted user work => CRITICAL rather than just major. New phenomeneon. Debugger re-uses editor windows when stepping between source files; good. But if the 'old' editor was one manually opened / edited it should not be closed, rather a new window should be opened.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
critical cannot be stale surely?
