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.
Since switching to JDK 5, I notice the editor caret is blinking even when explorer has focus. It's a bit disorienting. Not sure if there's anything we can do about it, but if we can hide the caret manually on mac os / jdk 5, we probably should. It definitely gets me confused about where focus is, I'm sure it does for others too.
I guess the focus is not transferred correctly. Turning on netbeans.debug.editor.caret.focus=true should give a clue of whether the caret receives focus gained/lost events properly. Tim could you please attach output when having this flag turned on? Thanks. A flag netbeans.debug.editor.caret.focus.extra=true gives some more info about blinking of the care etc.
Thanks, Mila, I'll try that and let you know. It may be a bug in Apple's Swing impl in JDK 5 (worked fine with JDK 1.4), but it would be nice if we can work around it somehow. I notice I can end up also with the Quick Search dialog remaining open in Explorer, with it having a blinking caret while I type in the editor. So I suspect some event that should be fired is not being fired.
This is startup, first setting focus to the editor: BaseCaret.focusGained(); doc=/space/nbsrc/platform/www/tutorials/nbm-povray-8.html Now I click the Projects tab. We lose focus then immediately get a focus gained event, but in reality the projects tab is what really has focus: BaseCaret.focusLost(); doc=/space/nbsrc/platform/www/tutorials/nbm-povray-8.html FOCUS GAINER: null BaseCaret.focusGained(); doc=/space/nbsrc/platform/www/tutorials/nbm-povray-8.html So focus is in the projects tab, but there is a blinking caret in the editor. Switching between explorer tabs does not trigger any additional logging. I switch to the Favorites tab and start typing a file name to locate that node. The quick search popup appears. No logging. I click in the editor. The following is logged: BaseCaret.focusGained(); doc=/space/nbsrc/platform/www/tutorials/nbm-povray-8.html BaseCaret.focusLost(); doc=/space/nbsrc/platform/www/tutorials/nbm-povray-8.html FOCUS GAINER: null Focus is now in the editor (despite the message above), and I have one blinking caret in the editor and another blinking caret in the quick search popup, which has not disappeared. So I'm guessing that on JDK 5 on Mac OS, focus events from text fields are really messed up. If we could find a workaround, though, it would be really good - it's incredibly distracting to not be able to tell which caret is alive. java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-110) Java HotSpot(TM) Client VM (build 1.5.0_06-61, mixed mode, sharing)
FWIW it appears to be fixed in Apple's JDK 6 developer preview. Nonetheless, I'll see if there is a workaround to be had in JDK 5 - I suspect it will be in use for some time, and the behavior is pretty bad there.
Well, I can't effectively fix it at the editor module level but I assume that core/winsys could possibly find some fix for this. Reassigning to core/winsys for further evaluation.
Milos please evaluate for me, thanks.
not sure how we can handle that in the core either. I have found additional usecase: 1. open properties window. 2. focus editor, have a blinking caret there in a method body 3. the method's properties should appear, select and start editing the modifiers field. ERROR: caret still blinking in editor. 4. go back to editor ERROR: the caret is still blinking in the property sheet and it's still in the editing mode more in issue #80810, where I also included a possible temporary patch for the propertysheet. reassigning to editor, for further evaluation. Please check if you could use similar technique in editor.
Sorry but a patch like the one from #80810 is not acceptable for the editor. I would like to keep the caret behavior simple - connected to focusGained/Lost events which should always work as expected. If not then we should IMHO search why the focus events do not come as expected - another focusGained() comes to the editor after switching to explorer. I thought that core/winsys could possibly send another focusLost() to the caret in this specific case but that's probably a naive idea. Tim you've said that it's fixed in the JDK 6 on the Mac. Could you please check what was the cause of the problem? (I expect there was a Mac issue entered and fixed for this problem). By understanding the cause we could possibly find a better way of how to workaround it (or there might be some workaround ideas described in the issue).
I've emailed my contact on the Apple AWT/Swing team.
apple's bug tracking system is not browsable.
Making a dup of (newer) issue 90371 since it contains more recent log. *** This issue has been marked as a duplicate of 90371 ***