Created attachment 20214 [details]
this is my message.log file for when I was last got NB into this state.

There is a lot of exceptions in your messgae.log file ;(

> Sometimes after having run a NetBeans session for
> a long time, I will suddenly no longer be able to
> select text in the source file editor.  I can
> neither mouse-down/drag not double-click text

DO you know where is a focus ? Can you see selected tab of actually
opened file ?

Thanks for help.

I can't reproduce it with NB4.1(200502031900) JDK1.5.0 / Linux Gnome

Next time this happens, I'll try to determine what object has focus.

When it's happened in the past, I've clicked the document in the
editing window & the window tab at the top of the pane, but nothing
seems to make it possible to select within the currently viewed document.

Clicking the file tabs does bring up that file's content.  I can click
amongst the tabs to bring up different files, but once the selection
capability stops working, I don't seem to be able to select text in
any  file.

Cheers,
Bill

Milos, your turn, you have the Mac :-) Although I can imagine this
could be tough to reproduce and fix :-(

I agree I think this will be tough to reproduce.

Having said that, it happened to me again yesterday.  The file's tab
in the editor tabbed pane was definitely selected at the time, but I
just couldn't alter any of the text in the window.

I should add I could "select" text, though only through a single means
- by mouse dragging across the text.  I couldn't double-click to
select strings, not could I single-click to place the insertion point
anywhere within the body of the file.

Moreover, the "selected" text I'd dragged over could neither be copied
or cut.

This is exactly the same behaviour I see every time my NB gets in this
 state.

Good luck.

Well, I got into this state once or twice as well.
No idea what could be wrong, if it's in our codebase or in apple's jdk.
I can't think of any code in winsys that could be responsible for
something like that.

 Given there are no reliable steps to reproduce (at least I was not
able to come up with any), it's close to impossible to debug.

Can you remember if you have done any Drag&Drop right before getting
into this state? 

Hi Milos,

If I remember correctly, typically this problem occurs when I return
to the editor window after having been somewhere else - debugging an
applications - or simply having returned to NetBeans after having been
working in an external web browser for a moment.

This makes it sound like it more related to the Mac OS X Window
Manager (and/or how the Window Manager interacts with the JVM to
properly give focus to a Java App) than anything internal to NetBeans
- though NetBeans is the only program I've experienced this problem
with.  Having said that, there aren't many Java Apps I'm using on a
regular basis, and my NetBeans gets near constant use, so if I'm going
to see a JVM bug anywhere, it would probably be in NetBeans.

Apple is pretty good about addressing significant system bugs.  I
would suggest contacting whatever entity at Apple handles system bugs
and notifying them of this issue.  I'm certain they'd want to know if
there is a significant JVM bug as fundemental as this.  The bug pretty
much makes any "editor" program useless once it's been hit.  I don't
know exactly who to contact, but when ever an application process
dies, there is a "Send Bug Report" window brought up by the system
that sends  the system log & system config info along with any
description you can provide of what you were doing in the system when
the app crashed.  Whomever is receiving these bug reports would be the
people to contact, obviously.

Next time I get hit with this problem - it happened twice again
yesterday - I'll track exactly what I was doing prior to the problem
showing itself.

Thanks for trying to help track this down.  When I get hit by it more
than once in a day, it can start to become really annoying and makes
it significantly harder to use NetBeans.

Cheers,
Bill

thanks for your comments.

Since you mention that deleting the var directory helps, it could be
useful to get it zipped and attached to the bug. (On assumption that
it could be reliably reproduced then on every startup of the IDE with
the given settings. However I'm a bit skeptical here, I think the IDE
just got into the same state right after restart but with no relation
to the cached setup)
For me the perstisted setup had no influence whatsoever and a restart
helped.

A thread dump of the IDE could be also of value.

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

it just happened to me again. I did Find in the editor right before it
occured.

reassigning to editor, it seems a duplicate or at least related to #52208

This is happening regularly for me on Solaris too.

I just discovered a workaround. Once the IDE gets into this state, bring up the
Find dialog - its text field has a caret. When I dismiss the dialog, the editor
has a caret again!

Hi All,

Just the other day I found another work-around that works on Mac OS X.

When NB gets in this state, simply switch to another open application (Apple Key
+ tab) then switch right back to NB.  The current source file then becomes
selectable again.

This has worked every time I've tried it so far.

It makes it sound like there is something about the current ojbect with "focus"
that gets fixed when the NB is given focus back by the OS.

Is there any chance the NB 'message.log' would contain any info useful for
diagnosing the root cause of this problem, if I were to check it right after
returning to NB from another app?

Cheers,
Bill

Bill, you might try to run NB with -J-Dnetbeans.debug.editor.caret.focus=true
(or add it to netbeans.conf) to see whether the editor's caret obtains the focus
in a right way. Thanks.

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

From ehucka in 52208:
"I have seen it three times for last two days. Cursor missed in inplace rename
textfield too. Nothing helps only to restart IDE."

This comment indicates that it's more likely a generic problem not directly
tight to the editor but rather to overall IDE functioning.

KeyEventBlocker was created to fix the issue #46907
This blocker consumes key events if it is active. It is activating by invocation
of Find Dialog and deactivating if Find dialog's "find what" combo box receives
focus. It seems to me that deactivating of the blocker is not performed in some
cases and it may cause some of the mentioned problems. 
For debuging this I have created debug messages info, that can be activated via
-J-Dnetbeans.debug.editor.blocker=true. A message will contain info about
attaching blocker listener to editor component, key event consuming and removing
listener from editor component. Please, update your build or download tomorrow's
dev build to help us with debuging of this problem. Thanks.

/cvs/editor/libsrc/org/netbeans/editor/ext/KeyEventBlocker.java,v  <-- 
KeyEventBlocker.java
new revision: 1.4; previous revision: 1.3

We can reproduce the problem. I will fix.

fixed in [maintrunk]

Please verify. Thanks.

/cvs/editor/libsrc/org/netbeans/editor/ext/FindDialogSupport.java,v  <-- 
FindDialogSupport.java
new revision: 1.67; previous revision: 1.66

/cvs/editor/libsrc/org/netbeans/editor/ext/KeyEventBlocker.java,v  <-- 
KeyEventBlocker.java
new revision: 1.5; previous revision: 1.4

I have fixed a problem that Tor discovered about find dialog. I saw the same on
Milos machine and after requesting focus to combo of find dialog the problem
dissapeared. It is mentioned blocker problem. However, selecting or caret
visibility problem is probably not fixed within this fix, thus for now I am
reopening the issue. For debuging focus problem please use a debug option, that
Mila adviced. Thanks.

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

If Issue 56107 is duplicate with this issue I must increase priority to P2. 
I invoked fix import. The dialog was empty but I didn't recognize it (reclick to
editor window). When I made some changes in a project settings a Project
Properties Changed dialog was displayed and IDE froze. All unsaved data were lost.

Changing platform to All as the focus problem was detected also on linux

I am able to reproduce this on linux (Fedora Core 3) in the current trunk build
after several invocations of FixAllImports. The strange thing is that not only I
loose the caret in editor, but also the nodes in project view or navigator do
not show a selection (activated node) - although the activated node is changing
properly (navigator window correctly updates its state when I click on some
other node). This might be a generic window-system issue or an issue related to
the JDK. I am running on JDK 1.5.0_01.
When I try Tor's workaroud - go to the Find dialog (using mouse, since shortcuts
do not work in this state), I get the caret there, however after closing the
dialog the caret is not shown in the editor - so the workaroud does not work -
the only workaroud I could find is to restart NetBeans. Moreover, once I close
the find dialog, I cannot reopen it again! When clicking on Find... or
Replace... menu items, nothing happens. Same for Go To Line... Other dialogs
(e.g. find in projects, or go to class, etc.) seem to be displayed properly even
for subsequent invocations. So, maybe this has something to do with editor actions?
Thread dump does not seem to show anything interesting (I will attach it).

Created attachment 21042 [details]
Thread dump.

OS -> All (seems to happen on Linux, Solaris, MacOS)

I also noticed that I am unable to attach a debugger to the IDE when in this
state - really weird!?$&( At least it happened twice to me - I was able to
attach a debugger when IDE ran normally. Then restarted, got IDE into this
state, then tried to attach debugger, and the debugger output window appeared,
but there was no text in it (no message like Attaching to a running process or
anything like that) and it did not attach to the IDE. When I restarted the IDE
again, I was able to attach the debugger. Then restarted, got the IDE into this
state and I was not able to attach the debugger with the same symptoms again.

When running with the property you suggested (for caret debugging), this is the
last message I see before the IDE gets into this state:
BaseCaret.focusLost() in
doc=/home.local/martin/JavaApplication12/src/javaapplication12/Main.java
j

From that time on, there are no messages when I am clicking in the IDE, opening
new files, etc. The caret is lost...
The "blocker" property does not seem to print out anything at all during the
whole IDE session.

I turned on JDK's focus debug info and reproduced the problem. Will attach my
message.log with all the debug messages from JDK and from the editor + some
messages I added. The IDE got into the state described by this issue after the
last stacktrace in the log.

Created attachment 21044 [details]
Log file containing debug messages.

The issue I described is not reproducible on JDK 1.4.2_04 -> could be a JDK bug
introduced in JDK 1.5.

I am able to easily reproduce this on:
JDK 1.5.0
JDK 1.5.0_01
JDK 1.6

With JDK 1.4.2_04 I was able to reproduce only a less fatal variant - the editor
curson disappeared, however once I click on some node in explorer, the selection
frame is there and when I then click back to the editor, the cursor appears - no
need to restart NB.

it happens on macosx in JDK 1.4.2 as well.

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

Yesterday this happened to me also when I started NB (with some files open in
the editor from the last run), then I closed some editor panes and the pane that
got focus as a result of that did not have a caret (even after clicking on it,
etc. - seems to be the same issue)

Milos, you said you reproduced it on MacOS X, do you mean you reproduced exactly
the same thing I described, or are you referring to the issue related to opening
the Find dialog which was fixed by Martin Roskanin as part of this issue?

sorry I confused the problems, I ws referring to the original Find problem. 

Milos, if you can reproduce the "blocker" problem (it can be workarounded by
opening Find dialog and focusing find what combo), please use a switch
-J-Dnetbeans.debug.editor.blocker=true and attach a debug messages. Thanks.

This issue was also reported in NetCAT 4.1 program.

I'm interested whether the problem is reproducible in the current builds, I
think the issue 56019 might influence the problem and it should now be fixed
(since Mar 23).
wjbug, could you please check any recent dev build (Mar 23 or later) whether you
can still reproduce? Thanks.

Sure.

I had been working with the 20050320 build for the past week or so and don't
recall having hit the problem (often?).

I picked up the 20050330 build yesterday and am working with that now.  If I see
this issue arise, I'll post a notice here with my message.log.

Cheers,
Bill

Maybe this could be caused by editor accessing swing API in non-AWT thread as
reported by issue 57354.

From Tor Norbye (seems like a related issue):

Martin Matula wrote:

> Hi Tor,
> the deadlock is already reported as a P1 issue -
http://www.netbeans.org/issues/show_bug.cgi?id=57354 


Thanks Martin, glad to hear it's being looked at!

I'm actually a lot more concerned about the other problem I'm seeing, since it's
happening all the time (I've only seen the deadlock once).

To reiterate, what happens is that suddenly the modifier key seems not work. For
example, I hit Ctrl-S to save, and I end up with an "S" added to my source
buffer instead. Similarly, other things like alt-shift-i causes an "I" to be
inserted, etc.

This bug MAY be related to the caret bug I've reported earlier (and that you
have bug reports for). To reiterate, that's the bug (which happens both on
Solaris and Mac for me) where the caret disappears and won't come back even when
you click. You can drag selection, and that works, but there's no visible caret,
so you can't type in new text etc.

Anyway - the workaround for the above bug I'm using is to go to the Edit menu
and select "Find". Then dismiss the dialog. That always "unjams" the caret
problem for me and I can continue working.

Well I discovered (and have verified a couple of times now) that the same
workaround works for this Linux/JDK1.5/NetBeans problem. Even though I have a
visible caret, when the modifier keys stop working I can go to the Find dialog
and when I come back they're operational again.

Hopefully that data point helps you. Perhaps it's the same root cause -- some ui
state manipulated from a non-dispatch thread (and therefore corrupted).

More from Tor:

I seem to discover the error-state when I try ctrl-space (code completion) on
something I really expect to complete, and nothing happens. That's when I try
ctrl-s etc. to verify that I'm in the error-state again.

So now I'm wondering if ctrl-space might actually be triggering the error
itself. So if you're fine-combing the code for errors, take a look in that area.

Yes -- I have nearly proved it now.

Here's what I did:
- In a class where I had a valid class imported named "JsfProjectHelper", I typed
 "JsfPr" and hit ctrl-space. Nothing happens. I hit Ctrl-S and instead of saving
I get "S".
- Next I open the Find dialog.
- When I come back I hit Ctrl-S again - it works (save, no S insert).  Aha, so
"Find" really does clear this state.
- Then I hit Ctrl-Space again - doesn't work, and a subsequent Ctrl-S shows that
it's unhappy again (inserts S).
- So I open the "Find" dialog, and dismiss it.
- This time, I just hit Ctrl-Space, nothing happens, then Ctrl-S -- error.

So it seems like Ctrl-Space is triggering this problem for me.

Let me know if you want me to run with any special diagnostics (assert
SwingUtilities.isEventDispatchThread() etc.) in the editor or elsewhere. 

The last problem described by Tor could be related to issue 48287 although Tor
claims it does not work for him even on Mac and that the modifier keys are
"broken" after Ctrl+Space.

Oops. Tor did not say it happens on Mac. He seems to be using JDS Quicksilver so
the last couple of comments from him should be a duplicate of issue 48287 -
sorry for confusion.

BTW besides the resident app on JDS the Ctrl+Space can AFAIK be used for
invoking input-methods mode as well e.g. in Chinese environment.

Changing TM to 4.2 and adding 41_HR_FIX kw according to:
http://www.netbeans.org/community/releases/41/high-resistance.html

I would like to ask performance team for a help. I'm wondering whether there
could be any Swing or AWT code executed outside of the event dispatch thread
causing problems described in this issue. Do you have any clue how this could be
done easily? I think such test would be beneficial for the whole IDE and it
could be run periodically e.g. before releases.

Oops, I didn't explain clearly what I wanted. I wanted to mention whether there
could be any automated test created by performance team for checking whether
there is not any Swing or AWT code running outside of the EDT (except the few
permitted methods).

Performance team is more interested in the cases where too much code is run
inside EDT :-)

I agree it would nice to have automated way to find out if some AWT/Swing things
are done outside EDT. Perhaps QA could take care of this?

Since I switched to jdk 1.5.0_03 I haven't seen it again.

Let me do a summary:

Original symptoms:
Suddenly it's not possible to select text in the source file editor. Neither
mouse-down/drag not double-click text items - the file simply becomes non-editable.

Reproducibility:
- the issue is random. We have no clear way how to reproduce the problem yet.
- mmatula presented a way of how to reproduce on Linux FC3 on JDK 1.5.0_01: 
 I am able to reproduce this on linux (Fedora Core 3) in the current trunk build
after several invocations of FixAllImports. The strange thing is that not only I
loose the caret in editor, but also the nodes in project view or navigator do
not show a selection (activated node) - although the activated node is changing
properly (navigator window correctly updates its state when I click on some
other node). This might be a generic window-system issue or an issue related to
the JDK. I am running on JDK 1.5.0_01.
When I try Tor's workaroud - go to the Find dialog (using mouse, since shortcuts
do not work in this state), I get the caret there, however after closing the
dialog the caret is not shown in the editor - so the workaroud does not work -
the only workaroud I could find is to restart NetBeans. Moreover, once I close
the find dialog, I cannot reopen it again! When clicking on Find... or
Replace... menu items, nothing happens. Same for Go To Line... Other dialogs
(e.g. find in projects, or go to class, etc.) seem to be displayed properly even
for subsequent invocations.

- it seems that the issue only occurs on certain JDKs. It could be a JDK bug or
 functionality problem that our code might trigger somehow.

Workarounds:
- sometimes the caret just disappears and can be restored by mouse (e.g. by
clicking on a node in the explorer and then clicking back into the editor).
- if it does not help then it may help to open and close some dialog with a text
field (e.g. an editor's find dialog). 
- if not then restarting of NB is usually sufficient.
- if even restarting does not help then removing of all the files from
$netbeans_userdir/var/cache before starting NB should always help.

JDKs where the problem was reproduced:
Linux:
 - JDK 1.5.0
 - JDK 1.5.0_01
 - JDK 1.6
 - JDK 1.4.2_04 (less fatal variant without necessity to restart the IDE)
not on JDK 1.5.0_03 (Eman states it does not happen for him there)

Mac OS X:
 - JDK 1.4.2_05

Other discussed issues:
 - issue 46907 [Find dialog delay] - deals with KeyboardFocusManager and
consumes certain key events so it might be related but the issue was integrated
in August 2004 so we would seen its effect earlier very likely.
 - issue 56019 [ide locked after invoking fix imports] - might be related but 
mmatula confirmed that he has reproduced even after this issue was fixed.
 - issue 57354 (dup of issue 57316 [DeadLock after/during code completition]) -
not related; it was a short time regression caused by fix of another issue.

Further steps:
 - it might be JDK issue (the different experiences of the reproducibility on
different JDKs indicate that) but the issue is random and there is no clear
reproducibility scenario yet.
 - we will attempt to check whether the IDE does not run any critical AWT/Swing
code outside of the EDT. The work on this is already in progress.
 - we may end up with a waiver for the issue if we find no clue.

 - if you have any idea regarding this issue please speak up. Thanks.

I'm afraid I've no clue on the cause of this problem, but I do have what appears
for me to be sure-fire work around - at least on my current platform (Mac OS X
v10.3.8, java version "1.4.2_05", Java(TM) 2 Runtime Environment, Standard
Edition (build 1.4.2_05-141.4), Java HotSpot(TM) Client VM (build 1.4.2-38,
mixed mode)).

All you have to do to get the caret back & be able to
select/copy/cut/find/replace again is to switch to another running application
then return to NB.  Upon return, the problem has always disappeared and all
"selection" oriented activites & the caret are functional again.

Unfortuntely, the problem can frequently re-occur requiring such an application
"switch" several times in a minute.  This high frequency re-occurance can
usually be eliminated by restarting NB.  At some point down the line, however,
the problem re-occurs.

I no longer believe it helps to clear out your .netbeans home directory - at
least not for my platform (listed above).  That doesn't appear to decrease the
frequency of this problem for me.

Good luck tracking this further.

Cheers,
Bill BUg

I was able to reproduce the issue on JDK 1.5.0_03-b06. I did it according to
Martin Matula's instructions - just keep on pressing Ctrl-Shift-F. This scenario
always leads to the bad state on Linux. So it doesn't seem that the issue was
completely solved with 1.5.0_03. 

The bug is not reproducible on Windows using this scenario. However I've
experienced the less fatal variant on WinXp with JDK 1.5.0_02. I could not
reproduce it on WinXP again.

Sorry, I ment Alt-Shift-F, not Ctrl-Shift-F.

Although this is reproducible using the obscure scenario I reported, it did not
happen to me for several weeks now during the normal work. So I guess this is
not so severe.

Another observation: if NetBeans gets into the bad state where you cannot type
any characters, try to switch to NetBeans console. Then switch back to NetBeans.
All characters you type now are sent to the previously opened console which
should not have focus at the moment. NetBeans do not regain focus for keyboard
after switching from to another window.

After scan for AWT code being run in non-AWT thread we have found and fixed
issue 57824.

Yesterday I have found reproduction case for this problem using a swing-only
application. The problem is that when a modal dialog is opened and closed in a
short period of time on Linux (either by posting the hiding and disposing of the
dialog by SwingUtilities.invokeLater() or using a short timeout timer e.g. 5ms)
then the focus can get broken and the app will not be focused properly and when
the frame is clicked it refuses to get focus.
Another problem is when using non-modal dialogs then when using a timer it can
get into state when the app can get the focus but the caret will not blink in
the editor pane even after repetitive clicking. Clicking into other app and back
fixes the problem.
It seems to work fine on Windows and also on Linux but with 1.4.2 JDK.
Attaching the jar that can be run with
  java -jar focusProblem15.jar
and also the source.

Created attachment 21637 [details]
Pure swing app jar that can be run with java -jar focusProblem15.jar

Created attachment 21642 [details]
Java source of the focusProblem15.jar

We will file a bug against JDK for this problem.

We have found a way how to workaround the problem on our side. Before the
imports progress dialog is closed and disposed we can use Thread.sleep(50) to
pause the AWT thread for 50ms. The value is empirical based on our observations
with the focusProblem15.jar swing app. BTW we cannot use Timer instead of
Thread.sleep() because then the dialog with possible import ambiguities
resolution does not show up properly. With that little patch we were unable to
reproduce the problem at all (on the same machine where we reproduced easily
before).
There was also an idea whether there isn't any method in the JDialog that could
indicate readiness of the dialog. I have went through the methods and the only
candidate I've found was dialogInit() but that one is called synchronously
directly from the constructor. Also there is isActive() but that indicates
something else. So probably not.
Anyway I have discussed the patch with the performance team and they agree with
it preliminarily. The Fix Imports action is not invoked so often that the 50ms
delay would matter too much. The patch is simple and should not cause any
regressions.

Created attachment 21653 [details]
Fix for delaying AWT thread for 50ms before closing the fix imports progress dialog

Fixed in main trunk:
Checking in
editor/src/org/netbeans/modules/editor/java/FixImportsProgressPanel.java;
/cvs/java/editor/src/org/netbeans/modules/editor/java/FixImportsProgressPanel.java,v
 <--  FixImportsProgressPanel.java
new revision: 1.5; previous revision: 1.4

Visual diff:
http://www.netbeans.org/source/browse/java/editor/src/org/netbeans/modules/editor/java/FixImportsProgressPanel.java.diff?r1=1.4&r2=1.5

I would like to ask Dan Prusa to review the fix and Roman Strobl from QE to
confirm the fix.

Marking as fixed. We will enter the JDK issue once we will know its number.

I agree with the proposed fix.

Confirmed by QE, please procceed with commit to 4.1 branch. Tested both on
sample application and on custom build.

Integrated into release41 branch:
Checking in src/org/netbeans/modules/editor/java/FixImportsProgressPanel.java;
/cvs/java/editor/src/org/netbeans/modules/editor/java/FixImportsProgressPanel.java,v
 <--  FixImportsProgressPanel.java
new revision: 1.4.2.1; previous revision: 1.4

There is still one problem. Under JDS if I hold Alt-Shift-F editor may loose
focus and caret. The workaround is simple - clicking by mouse into editor
regains editor focus. Mila will try to fix this.

I will keep the issue as fixed for now because this issue is caused by a JDK bug
described above. We'll attach link to it soon once the bug is filed.

One more comment, the focus sometimes gets lost after 1 invocation of fix imports. 

The JDK bug which causes this issue was submitted into bugster as #6265294.

Verified, this is a JDK bug.