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.
Toggle line breakpoint and Run to cursor actions are disabled in recent daily builds. It is a regression and it blocks automated tests. To reproduce: - create java project - add line of code to JavaApplication1.java - put cursor at added line - open Debug main menu but actions "Run to Cursor" and "Toggle Line Breakpoint" are disabled Product Version: NetBeans IDE Dev (Build 201206280002) Java: 1.7.0_06-ea; Java HotSpot(TM) 64-Bit Server VM 23.2-b05 System: Windows 7 version 6.1 running on amd64; Cp1250; en_US (nb)
Product Version: NetBeans IDE 7.2 RC1 (Build 201206272359) Java: 1.7.0_05; Java HotSpot(TM) Client VM 23.1-b03 System: Linux version 3.0.0-12-generic running on i386; UTF-8; cs_CZ (nb) User directory: /home/cesilko/.netbeans/7.2rc1 Cache directory: /home/cesilko/.cache/netbeans/7.2rc1 Works for me in NetBeans 7.2 Release Candidate.
It's strange, that these actions are disabled in menu, but they work via shortcuts. It might be caused by the fix of issue #210416.
Fixed by changeset: 225195:19c4e2541b22 http://hg.netbeans.org/main/rev/19c4e2541b22
It still fails in automated tests. To reproduce: - open java.kit\test\qa-functional\src\org\netbeans\test\ide\IDECommitValidationTest.java - run test (Ctrl+F6) - it creates new project and Sample1.java file. When testDebugging starts it selects one line in Sample1 and tries Ctrl+F8 to toggle breakpoint. But it is not enabled. You can right-click manually in editor but nothing happens. - hints for running: you need just the following test cases (others can be commented out) conf = conf.addTest("testNewProject"); conf = conf.addTest("testNewFile"); conf = conf.addTest("testEditor"); conf = conf.addTest("testDebugging"); - you can add to project.properties test.run.args=-Dorg.netbeans.spi.debugger.ui.level=100
Created attachment 121821 [details] Output with spi.debugger.ui logging.
This looks like a bug of EditorRegistry. The call toggleBreakpointAction.performMyShortcut(eo) from IDEValidation.testDebugging() calls: component.getFocus(); in Action.performMyShortcut() The getFocus() call changes the focused component. Before that call, QuietEditorPane has the focus and after that call I get focusLost property change event: oldValue=org.openide.text.QuietEditorPane newValue=org.netbeans.core.spi.multiview.text.MultiViewCloneableEditor[SampleClass1.java *] Therefore, when I ask for EditorRegistry.focusedComponent(), it gives me null, since it's likely, that c.isFocusOwner() is false in focusedComponent() method. However, later somehow QuietEditorPane becomes focused again, but I do not get any focusGained PropertyChangeEvent from EditorRegistry about this. This is why I keep thinking, that no editor pane is focused. But suddenly, EditorRegistry.focusedComponent() starts to return QuietEditorPane, without any preceding focusGained event.
I'm not sure about the component, please reassign accordingly if necessary. From the editor point of view, this might not be a regression. Debugger has started to use EditorRegistry since 7.3.
Created attachment 121898 [details] Log of the focus changes initiated by ComponentOperator.getFocus()
The bug in EditorRegistry was identified. As can be seen in the attached log, the ComponentOperator.getFocus() changes the focus from the QuietEditorPane to MultiViewCloneableEditor. This is logged by DefaultKeyboardFocusManager: java.awt.FocusEvent[FOCUS_GAINED,permanent,opposite=null,cause=NATIVE_SYSTEM] on MultiViewCloneableEditor[...] java.awt.FocusEvent[FOCUS_LOST,permanent,opposite=MultiViewCloneableEditor[...],cause=NATIVE_SYSTEM] on org.openide.text.QuietEditorPane[...] This causes focusLost event to be fired. But then there comes java.awt.FocusEvent[FOCUS_GAINED,permanent,opposite=null,cause=ROLLBACK] on org.openide.text.QuietEditorPane[...] from the DefaultKeyboardFocusManager. One would expect, that opposite would be set to null on the FocusEvent, but unfortunately, this is not true. We get: EditorRegistry.FocusL.focusGained(java.awt.FocusEvent[FOCUS_GAINED,permanent,opposite=QuietEditorPane[...],cause=ROLLBACK] on org.openide.text.QuietEditorPane[...]) Since getSource() == getOppositeComponent(), c == origFocused in _focusGained() and therefore the created events are not fired (newValue == oldValue).
It actually looks like a defect in AWT rather then in EditorRegistry. Anyway, it's fixed by changeset: 226423:fc00ef22eb14 http://hg.netbeans.org/main/rev/fc00ef22eb14
Integrated into 'main-golden', will be available in build *201207120002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/fc00ef22eb14 User: mentlicher@netbeans.org Log: #214904: When we get focusGained with identical components, set the origFocused to null, so that focusGained event is fired.
Verified. Thank you for your effort.