Bug 60235 - editor focus sometimes lost when switching tabs
editor focus sometimes lost when switching tabs
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Window System
4.x
Macintosh Mac OS X
: P2 (vote)
: 6.x
Assigned To: Milos Kleint
issues@platform
5.0-beta-waiver
: RELNOTE
: 59965 60791 62062 63542 64044 66559 71627 71636 72425 74543 86087 (view as bug list)
Depends on: 65326
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-18 17:17 UTC by jportway
Modified: 2008-12-22 11:44 UTC (History)
10 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jportway 2005-06-18 17:17:25 UTC
I suspect this may be an OSX only issue, because I can't believe it would have been missed otherwise.
There are two variants of the problem:

1) after clicking between editor tabs a caret appears in the editor but when you type no text appears. 
Subsequently clicking on another editor tab, and then clickin in the editor pane to set the insertion 
point causes all of the backlog of keypresses to be delivered - so suddenly everything that you typed 
before into the other editor pane gets typed into this one.

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. This happens to me about twice a day.
Comment 1 Miloslav Metelka 2005-06-28 17:33:20 UTC
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.
Comment 2 Martin Roskanin 2005-07-12 13:11:23 UTC
*** Issue 60791 has been marked as a duplicate of this issue. ***
Comment 3 Miloslav Metelka 2005-09-08 11:19:15 UTC
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.
Comment 4 Roman Strobl 2005-09-09 14:01:33 UTC
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?
Comment 5 Martin Matula 2005-09-10 23:49:56 UTC
*** Issue 64044 has been marked as a duplicate of this issue. ***
Comment 6 Martin Matula 2005-09-11 12:52:02 UTC
*** Issue 62062 has been marked as a duplicate of this issue. ***
Comment 7 Martin Matula 2005-09-11 12:53:54 UTC
Seems that the cursor disappears also in other situations, than just switching
tabs. See the recent duplicate.
Comment 8 Roman Strobl 2005-09-11 13:11:50 UTC
Milosi and Jaro, have you ever experienced such a problem? It seems to be
Mac-specific. Thanks.
Comment 9 Tomas Danek 2005-09-12 11:51:13 UTC
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)
Comment 10 Roman Strobl 2005-09-13 13:58:57 UTC
*** Issue 63542 has been marked as a duplicate of this issue. ***
Comment 11 wjbug 2005-09-14 06:22:35 UTC
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
Comment 12 Miloslav Metelka 2005-09-16 15:39:58 UTC
Reassigning to Tomas H. - could you please try to reproduce the steps given in
the issue 62062? Thanks.
Comment 13 Miloslav Metelka 2005-09-16 16:47:36 UTC
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.
Comment 14 timbray 2005-09-17 16:22:30 UTC
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
Comment 15 timbray 2005-09-17 20:30:20 UTC
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...
Comment 16 _ ttran 2005-09-17 22:14:24 UTC
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.
Comment 17 Milos Kleint 2005-09-18 20:41:22 UTC
#62947 seems to be a duplicate of one of the scenarios mentioned here.
Comment 18 Jaromir Uhrik 2005-09-19 09:37:42 UTC
I have the same experience with it as Trung has. Milosi I think it is not the
same issue as #62947. 
Comment 19 David Simonek 2005-09-19 10:51:36 UTC
Passing to Milos.
Comment 20 _ ttran 2005-09-20 13:23:28 UTC
*** Issue 59965 has been marked as a duplicate of this issue. ***
Comment 21 _ ttran 2005-09-20 13:25:05 UTC
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.
--%<---
Comment 22 Milos Kleint 2005-09-20 14:06:48 UTC
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.
Comment 23 Milos Kleint 2005-09-22 10:10:43 UTC
I have filed a bug against apple's jdk 1.5. their tracking number is: 4268664

Comment 24 Milos Kleint 2005-09-22 10:31:27 UTC
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.
Comment 25 Milos Kleint 2005-09-22 12:09:57 UTC
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
Comment 26 Jaromir Uhrik 2005-09-22 15:37:59 UTC
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.
Comment 27 Milos Kleint 2005-09-23 12:58:26 UTC
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.
Comment 28 jportway 2005-09-28 13:04:08 UTC
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.
Comment 29 jportway 2005-09-28 13:33:02 UTC
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.
Comment 30 jportway 2005-09-28 13:37:25 UTC
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.
Comment 31 Milos Kleint 2005-09-29 06:58:16 UTC
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.
Comment 32 lordy 2005-09-30 09:28:02 UTC
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.
Comment 33 Miloslav Metelka 2005-10-12 10:52:17 UTC
*** Issue 66559 has been marked as a duplicate of this issue. ***
Comment 34 Jan Chalupa 2005-10-26 08:42:39 UTC
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.
Comment 35 Milos Kleint 2005-11-11 10:05:00 UTC
marking as 5.0_WAIVER_REQUEST, the wrong behaviour is a bug in apple's jdk 1.5.
Comment 36 Marian Mirilovic 2005-11-15 10:48:14 UTC
No objection against 5.0 waiver, neither from NetCAT ... isue waived for NB 5.0
Comment 37 Milos Kleint 2006-01-11 13:53:35 UTC
apple bug #4307018 seems to be fixed in release4 DP3, we can remove our hack in
AbstractModeContainer.focusSelectedTopComponent
Comment 38 Jaromir Uhrik 2006-01-20 09:25:19 UTC
*** Issue 71627 has been marked as a duplicate of this issue. ***
Comment 39 dimaulupov 2006-03-18 10:45:04 UTC
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.
Comment 40 Milos Kleint 2006-03-20 07:03:02 UTC
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..
Comment 41 dimaulupov 2006-03-20 09:34:47 UTC
Thank you!
It works fine with that version of java.
Comment 42 Milos Kleint 2006-03-27 08:04:45 UTC
*** Issue 72425 has been marked as a duplicate of this issue. ***
Comment 43 Marian Mirilovic 2006-04-07 07:56:22 UTC
*** Issue 74543 has been marked as a duplicate of this issue. ***
Comment 44 Milos Kleint 2006-07-10 07:47:58 UTC
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.
Comment 45 Milos Kleint 2006-10-17 12:40:04 UTC
*** Issue 71636 has been marked as a duplicate of this issue. ***
Comment 46 Milos Kleint 2007-08-17 10:21:16 UTC
*** Issue 86087 has been marked as a duplicate of this issue. ***


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo