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.
Situation occurs after deleting one of several tabs in the output tab. To reproduce - In the "Output" tab have mutliple sub tabs - have undo or redo toolbar buttons enabled (make change in edit window if needed) - delete one of the sub tabs in the output tab Notice that keystrokes are delivered to the edit window, but the undo/redo buttons are disabled. Click in the edit window and the toolbar buttons become enabled. When in this strange state the keyboard shortcuts for undo/redo also fail.
Will this issue be getting fixed soon? Would be great to see it in 6.9! I know I can work around it by clicking directly in the editor Window, but I have to stop what I'm doing to do that. Kind of interrupts the work flow. Defeats the purpose of "Focus when Cursor is Over".
I have another circumstance in which this symptom occurs. It's been going on since I installed NB 6.8. Things worked fine in earlier releases. I now have NB 6.9.1. I have Windows set up so that the input focus goes to the window with the cursor, but without auto-raise. I am editing along in NB. The UNDO button is enabled. I move my cursor to another window and type into that window, and when I do that, I can see the UNDO button in NB become disabled. Then I move my cursor back to NB I continuing editing along, but the UNDO button does NOT get enabled... until I actually click on something in NB. Only then does the UNDO button get re-enabled. The thing that makes things difficult for me is not the UNDO button itself, however. No, the entire ability to UNDO doesn't work. When I click the undo key, it doesn't work. I have to stop, take my hand away from the keyboard, and click the mouse button, then go back to what I was trying to do. This might seem like a minor annoyance, but I am using the jVi plugin, and I use NB on Linux as well and vi and vim all over the place. I don't have to think about what I'm doing when I am editing... until the vi "u" command quits working. The context switch is annoying and painful. The problem isn't with jVi. I discussed this with the jVi developer. And when I turn jVi off, the UNDO function still gets disabled.
I can confirm that this problem still exists in 7.0.1
Mila, Do you have an idea of what is going on with this, or can you suggest a way I can debug it? If I discover a straightforward fix I could patch it; with the reworking of undo/redo global action (I forget exactly what that was about) I had thought this might get fixed. There might not be a simple fix within NetBeans. For jVi I might be able to find a hack; maybe something like detect "focus gained", wiggle something in NetBeans to get more than just keyboard focus on the editor.
I don't know internals of jVi implementation but "u" command just delegates to editor's undo action? Or mark_barnes without jVi the Ctrl+Z just does nothing?
Note that this happens without jVi.
(In reply to comment #5) > "u" command just delegates to editor's undo action? (I responded to quickly) Note that the icons for undo/redo are disabled when in this state. (I forget exactly what jVi does, but the intent is to delegate IIRC). Since the icons are disabled, this would imply that jVi is delegating (I can check if important).
I just turned on some logging. Following is some jVi debug output when working in the editor and the undo icon is active and an output window sub-tab is X'd. The output window gets activated as seen in the trace. But the JEP keeps keyboard focus. The undo icon is deactivated. Note in the trace key events are still being delivered to the editor. As a workaround, entering Ctrl-0 (that's a zero) makes the editor the active TC and gets back to a stable state. KeyAction: ViLeftKey: e002(2) 0 virt trackTC: activated oldTC: LogTree.java:JavaEditor@bc2950 'editor' : nPanes = 1 ep:6 QuietEditorPane@17d8938 tc: LogTree.java:JavaEditor@bc2950 isEditable true Activation: AppViews.deactivateCurrent: trackTC: activated newTC: Output:IOWindowImpl@2ece00 'output' : nPanes = 4 ep:0 JEditorPane@1934d9d tc: Output:IOWindowImpl@2ece00 isEditable false NOT-JVI ep:0 JEditorPane@1446e33 tc: Output:IOWindowImpl@2ece00 isEditable false NOT-JVI ep:0 JEditorPane@1089257 tc: Output:IOWindowImpl@2ece00 isEditable false NOT-JVI ep:0 JEditorPane@2dbef tc: Output:IOWindowImpl@2ece00 isEditable false NOT-JVI KeyAction: ViLeftKey: e002(2) 0 virt
My #5 question was useless since Ctrl+Z is no longer mapped directly to editor's undo action (it used to be in the past). It can be seen in NbEditorKit.NbUndoAction: public @Override void actionPerformed(ActionEvent evt, JTextComponent target) { Document doc = target.getDocument(); if (doc.getProperty(BaseDocument.UNDO_MANAGER_PROP) != null) { // Basic way of undo super.actionPerformed(evt, target); } else { // Deleagte to system undo action // Delegate to system undo action UndoAction ua = (UndoAction)SystemAction.get(UndoAction.class); if (ua != null && ua.isEnabled()) { ua.actionPerformed(evt); } } } If system UndoAction is not enabled there would be no undo done. I was able to reproduce the problem thru output tabs on Ubuntu 11.04. I'll attempt to fix it.
We should fix this into 7.1.
I can confirm that this problem still exists in NB 7.1.1, NB 7.1.2, and NH 7.2 rc1.
Still a problem in NB 7.2. I may not be losing data, but it's still a major pain to me. Undo just plain doesn't work. I have to click in the editor to get it to work again.
Still a problem with 7.2.1. Is it fixed in 7.3? I'm waiting for 7.3.1.
Tested in 7.4dev, used steps from comment #1 - seems to work fine. Note that in 7.4 the output window has its own caret when focused.
Using 7.4 beta it still fails. To reproduce: - Install 7.4 (no import settings) - Open some project - Set breakpoint in main - Debug File (context menu on file with main in it) - Get two sub-tabs of output tab: javaApp1(debug single), DebuggerConsole breakpoint is reached, execution pauses. - Add a character to open file, notice that undo button becomes active - delete, by pressing the sub-tab's "X", javaApp1(debug single) observe: press some arrow keys, notice that cursor moves in editor window undo button is not active if click on tab for editor window, then the undo button becomes active
I see. In the buggy state, the EditorRegistry.focusedComponent() == EditorRegistry.lastFocusedComponent() == the modified source's editor pane. At the same time, the WindowManager tracks the core.io.ui.IOWindow as the active TopComponent. The Undo/Redo Actions however track the WindowManager instead of the EditorRegistry, so it disables itself as non-editor window is enabled. I would recommend to watch EditorRegistry from undo/redo
After consulting Mila and thinking once more, it seems that the defect may be in better fixed in the window system. In the 'buggy' situation, the Swing keyboard focus manager forwards events to the editor, the caret blinks in the editor, so it seems appropriate to ensure that even the activatedTopComponent shifts to the editor.