Bug 60235

There is a similar problem with modal dialogs opened on Linux. The dialog
sometimes does not get focus properly so a text field in the dialog does not
show the typed text. 
The workaround is to click outside of the modal dialog and then back to it and
the  typed letters suddenly appear.
I'm sure the JDK issue was entered for this problem already so I was searching
for it. I've found http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6267706
but I'm not confident whether it's the right issue, so I will first double-check
that.

*** Issue 60791 has been marked as a duplicate of this issue. ***

jportway, as this was reported against 4.1 could you please try to reproduce
with the present dev builds whether this problem occurs there as well?
Romane could you please try to reproduce on your Mac machine whether it's
reproducible on our side as well? Thanks.

I have tried to reproduce it on 4.1 on our lab machine but without success. Is
there anything special you do in order for the bug to occur? Can you try it to
reproduce it on latest daily builds?

*** Issue 64044 has been marked as a duplicate of this issue. ***

*** Issue 62062 has been marked as a duplicate of this issue. ***

Seems that the cursor disappears also in other situations, than just switching
tabs. See the recent duplicate.

Milosi and Jaro, have you ever experienced such a problem? It seems to be
Mac-specific. Thanks.

Not *only* mac-specific, i was able to reproduce on sol9/sparc - see dup issue
62062! There are also some steps to reproduce to reproduce on MAC (however, this
didn't work for me on sparc)

*** Issue 63542 has been marked as a duplicate of this issue. ***

I just wanted to confirm, I'm still seeing behavior '2' described in the
original post with the latest dev builds (well almost the latest - the v4.2/v5
20050907 dev build).

I've been seeing it periodically since 4.0, and have seen it in many different
dev builds of 4.0, 4.1, 4.2 & now v5.  I seem to see it much less often now than
I used to.

This is a rather inexact statement, however, since I'm not really certain I know
all the conditions that can put NB in this state.  I generally get there via the
route described in previous posts to this issue, but not always.  I've also
noticed double-clicking an editor tab (causing the Navigator & Projects/Files
panes to disappear) can "sometimes" put you in this state, but not always.

For me, none of the work arounds (e.g., open & closing a modal dialog such as
the 'Open File' dialog) seem to work.  I always need to restart NB to get rid of
the problem.

I also frequently experience behavior '1' as described in jportway's original
post, though simply context switching (typing the apple-tab keys) to another
application then back to NB clears this state - and dumps any typed characters
that hadn't previously shown up at the current insertion point.

Cheers,
Bill Bug

Reassigning to Tomas H. - could you please try to reproduce the steps given in
the issue 62062? Thanks.

Tomas tried to reproduce the steps in the issue 62062 and with some added
debugging we have found the component that grabs the focus out from the editor
pane on the Mac (the opposite component in the focusLost() focus event in the
BaseCaret). It's very likely the pane that displays the list of the active
editor windows (the 'v' on the right of the editor tab bar). The component was
95x20 and we had only one file opened and as soon as we've opened another file
the reported component was 95x40.
 Here is the output from the debugging:

BaseCaret.focusGained() in  doc=/tmp/JavaApplication1/src/javaapplication1/DDD.java
BaseCaret.focusLost() in 
doc=/tmp/JavaApplication1/src/javaapplication1/DDD.java 
focus-gainer=java.awt.Panel[panel0,978,60,95x40,layout=java.awt.BorderLayout] 
focus-event=java.awt.event.FocusEvent[FOCUS_LOST,permanent,opposite=java.awt.Pane
l[panel0,978,60,95x40,layout=java.awt.BorderLayout]] on 
org.openide.text.QuietEditorPane[,0,0,814x604,layout=javax.swing.plaf.ba
sic.BasicTextUI$UpdateHandler,alignmentX=null,alignmentY=null,border=jav
ax.swing.plaf.basic.BasicBorders$MarginBorder@973ec6,flags=296,maximumSi
ze=,minimumSize=,preferredSize=,caretColor=java.awt.Color[r=0,g=0,b=0],d
isabledTextColor=javax.swing.plaf.ColorUIResource[r=128,g=128,b=128],edi
table=true,margin=java.awt.Insets[top=0,left=0,bottom=0,right=0],selecte
dTextColor=apple.laf.CColorPaintUIResource[r=0,g=0,b=0],selectionColor=a
pple.laf.CColorPaintUIResource[r=180,g=213,b=213],kit=org.netbeans.modul
es.editor.java.JavaKit@caedc8,typeHandlers=]

 I have improved debugging in BaseCaret to show this information:
Checking in libsrc/org/netbeans/editor/BaseCaret.java;
/cvs/editor/libsrc/org/netbeans/editor/BaseCaret.java,v  <--  BaseCaret.java
new revision: 1.117; previous revision: 1.116

 The debugging can be turned on by using
-J-Dnetbeans.debug.editor.caret.focus.extra=true

 Reassigning to core/ws to find out why the file list grabs the focus.

In qbuild 200509151455, I can reproduce this 100% of the time on OS X (10.4.2, java 1.5.0_02-56) as 
follows:

1. I have projects/navigator/runtime/files wondows pushed-aside (what's the right term, they're 
minimized off at the left and pop up when you put the cursor over them).
2. I have a bunch of files open, so lots of tabs across the top.
3. I regularly use control-tab to switch files.
4. Bring up search window with command-F
5. Search successfully for something
6. Dismiss window with ESC
7. Focus is lost.
8. Can bring it back by clicking in the editor, or by switching away from NB & back with command-tab

More random facts about this bug:

1. There is a well-known workaround: using the menu, select Edit/Find.  Dismiss the dialogue and you 
have focus back.

2. Odd observation. Sometimes when I do this sometimes the Find dialogue is in a sort of weird state, with 
the history drop-down on "Find what" dropped down and holding the focus...

I can reliably reproduce this problem on my Powerbook (OSX 10.4, JDK 1.5, NB dev
build).  Just have two editor tabs.  Caret blinking on the first one. Mouse
click on the other tab caption.  It switched.  But no caret blinking.  Mouse
click inside the second tab to set the focus.  Click on the caption of the first
tab.  No caret.

I can't reproduce this problem with JDK 1.4 on the same machine.

#62947 seems to be a duplicate of one of the scenarios mentioned here.

I have the same experience with it as Trung has. Milosi I think it is not the
same issue as #62947. 

Passing to Milos.

*** Issue 59965 has been marked as a duplicate of this issue. ***

See also issue 59965 for another way how to lose the focus

--%<---
When the open files drop list is used to change to another open file the
cursor's focus is lost on all files 
until something interrupts focus ie. preferences are opened. It is not apparent
what has the focus. Files 
also cannot be navigated with the ctrl -> or ctrl <-  commands or the use of
backwards and forwards 
jump-list commands to follow code.
--%<---

For last usecase I have a fix ready locally, however only on 1.4.2 jdk, on 1.5
it's still not working. it's also probably the only case that appears on 1.4.2
as well.

I have filed a bug against apple's jdk 1.5. their tracking number is: 4268664

i have commited a workaround for the problem into trunk.
it seems to cover 99% of the usecases with switching tabs. Jaro, can you please
test it on your machine and let me know the result? I would put the change to
the beta branch as well.

Checking in
windows/src/org/netbeans/core/windows/view/ui/AbstractModeContainer.java;
/cvs/core/windows/src/org/netbeans/core/windows/view/ui/AbstractModeContainer.java,v
 <--  AbstractModeContainer.java
new revision: 1.16; previous revision: 1.15

Milosi, the fix doesn't work for form-files. For other works fine. Now I am able
to reproduce according to following steps:
1.Create new JFrame (or any kind of form)
2.Switch from Design mode to Source mode
3.Type to editor <SomeString> - it is not possible to write
Workaround is to switch another editor tab by click on it (<SomeString> is
added! to current editor tab) and click back to form - then the editing is OK.

i've created an issue for the most irritating case #64984 and commited a
"workaround" for jdk 1.5 on mac.
switching tabs by mouse or Ctrl-Tab mostly work. stuff like maximizing
components still doesn't. removing the bet showstopper keyword from this bug.

In certain recent builds this bug seemed less prevalent (sorry I didn't keep track of which ones), but in the 
sept 15th Q-Build (which I'm currently using) it's back with a vengeance. I can't work for more than about 
5 minutes before having to restart the IDE. Personally, I would absolutely consider this a blocking bug. It 
might not be important to other platforms, but it pretty much renders Netbeans unusable on the Mac.

to clarify - one form of the bug (the form that juhrik describes above) is fairly easily worked around by 
switching tabs and switching back, but there is another form (or possibly a completely separate bug) that 
is not cured by simply switching tabs, and which as far as I can tell requires a restart of the IDE.

In the problem juhrik describes the editor caret usually still remains visible (although no input seems to 
work), in the othe case there is no visible caret.

oh (sorry to keep posting separate comments) this is definitely NOT a jdk 1.5 issue - the more severe 
version of the problem (requiring restart) is happening for me running under jdk 1.4.2.

jportway, please try with the 5.0 beta, it should be more severe. in the current
trunk there's more workarounds included. the sept 15th q-build had NO fixes in
this area so it has to be the worst performing build.

re: jdk 1.4.2 - there was just one usecase I figured on 1.4.2 and that was
switching editor tabs through the Ctrl-Tab or the document list popup.

if you still encounter issues in post-beta builds, please file them as separate
issues and make this one depend on it. I'm quite lost in the various usecases
that are described here. Referencing back to previous comments makes orientation
even harder.

RE: 2) After clicking between editor tabs no insertion caret appears in the editor pane even after clicking 
on it. Even switching tabs again doesn't help and it's impossible to get the editor caret back again. Any 
text entry (including keyboard shortcuts for menu options) seems to be lost. The only solution I have 
found for this is to restart netbeans.


I run Mac OS X 10.4 and Java 1.5.0_04. Somethime i get the focus back working when i open the Output 
window during a build.

*** Issue 66559 has been marked as a duplicate of this issue. ***

Workarounds for some of the reported problems have been integrated, more bugs
have been filed against Apple JDK. There's not much we can do here. Downgrading
to P2, a candidate for 5.0 waiver.

marking as 5.0_WAIVER_REQUEST, the wrong behaviour is a bug in apple's jdk 1.5.

No objection against 5.0 waiver, neither from NetCAT ... isue waived for NB 5.0

apple bug #4307018 seems to be fixed in release4 DP3, we can remove our hack in
AbstractModeContainer.focusSelectedTopComponent

*** Issue 71627 has been marked as a duplicate of this issue. ***

This bug still exists.
mkleint said that "apple bug #4307018 seems to be fixed in release4 DP3, we can remove our hack in
AbstractModeContainer.focusSelectedTopComponent" but it doesn't seem to be fixed.

Maybe I don't have that "release4 DP3", my java version is "java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-83)
Java HotSpot(TM) Client VM (build 1.5.0_05-48, mixed mode, sharing)"

Trunk and 5.5 daily just have been switched to java 1.5_06 so right now it is impossible to use latest 
netbeans versions with java 1.4 (where netbeans doesn't have this bug).

So maybe it is possible to return some "hack" because that issue is a very irritating one on a Mac.

With "the bug still exists" I mean:
1) Open two files.
2) Change from one to other by clicking in the small "v" menu on right top corner.
3) Change back with clicking on file headers.
4) Focus gone.

Sometimes it is not enough to just open some dialog to gain focus back, you have to close&open IDE.

dimaulupov: you need java 1.5.0_06 / VM 1.5.0_55 at least. AFAIK you need to
subscribe to the apple developer network to be able to download it..

Thank you!
It works fine with that version of java.

*** Issue 72425 has been marked as a duplicate of this issue. ***

*** Issue 74543 has been marked as a duplicate of this issue. ***

closing as fixed.
1. this is promary a problem in the apple's jdk, which was fixed in the recent
version.
2. we haven't received any recent reports regarding this issue, so people
upgraded  and/or our workarounds proved sufficient.

*** Issue 71636 has been marked as a duplicate of this issue. ***

*** Issue 86087 has been marked as a duplicate of this issue. ***