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.

Bug 5697 - Sometimes an unselected editor window is receiving key strokes instead of the selected one.
Summary: Sometimes an unselected editor window is receiving key strokes instead of the...
Status: CLOSED WORKSFORME
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 3.x
Hardware: All All
: P2 normal (vote)
Assignee: _ ttran
URL:
Keywords:
: 8990 9333 10474 11723 13572 14080 20088 (view as bug list)
Depends on:
Blocks:
 
Reported: 2000-02-10 01:02 UTC by Jesse Glick
Modified: 2008-12-23 14:25 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
patch to fix the bug in release31 (1.59 KB, patch)
2001-07-20 20:29 UTC, _ ttran
Details | Diff
This log file describes the focus problem (241.87 KB, text/plain)
2001-07-20 20:48 UTC, David Konecny
Details
logs of focus problem for 3.2 build19 (377.12 KB, text/plain)
2001-07-20 20:48 UTC, David Konecny
Details
ide.zip containing the latest log (created with maybe 10 days old build) (81.43 KB, application/octet-stream)
2001-07-20 20:48 UTC, David Konecny
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2000-02-10 01:02:28 UTC
Sometimes editor pane has focus, cursor is in it blinking etc., but
keys do not seem to work. In fact all keys are being sent to another
pane which is hidden; so you can e.g. type things and the other file
will become modified. After using Alt-Left e.g. to switch into it,
maybe? Clicking with mouse in pane does not help, nor switching to
another pane and back again. You must close the pane and reopen it to
be able to edit it again.

481, recent JDK 1.3, Win2000 and maybe NT also. Perhaps this is a window manager bug, I do not know.


[jglick] Also from Ognen Ivanovski [milkman@soros.org.mk]:

There were few opened files in the editor window. Somehow I managed to
see the cursor in the last file (the rightmost tab selected) and when typing
the characters went to the file asociated with the tab left-next to the
viewed file. I closed the files, opened them again and this did not repeat.
I think i tried to paste or delete before all this happened.
Comment 1 Marek Grummich 2000-07-25 09:09:59 UTC
Priority is changed to P4 (normal).
Comment 2 Petr Slegr 2000-11-29 10:42:59 UTC
Here is reproducible case:
Update parser database for Developement filesystem
From exmaples/texteditor directory open Ted.
Go to the line: 161 and on About do Go to source (Alt-O) action.
Click to About window to give it focus.
Press Alt-K (twice) and do Alt-O Alt-K till Alt-K stops to work.
Now try typing -> you type in About file.
Comment 3 vnemec 2000-11-29 14:30:59 UTC
Another reproducible case - follow these steps in some [boston] build:
a) create some class containing at least two hardcoded string
b) open i18n window ("Tools > Internationalize")
c) create new resource bundle (click 'New'...)
d) click 'Replace' - 'plain' editor with properties file should open
e) close i18n window
f) open i18n window again
g) create ANOTHER resource bundle
h) click 'Replace'...
- you can now switch editor to original source file - the blinking cursor
appears (as supposed) but everything you type is inserted into one of opened
resource bundles (not to java source) - the target file for input strongly
depends on position of cursor in source file and operation you're trying to
make....
Comment 4 _ ttran 2001-01-10 13:57:59 UTC
*** Bug 8470 has been marked as a duplicate of this bug. ***
Comment 5 _ ttran 2001-01-11 12:03:59 UTC
the root of the bug is that focus is set to the wrong component.  This cannot be
a bug in editor.  There must be something wrong in the window system implementation
Comment 6 _ ttran 2001-01-11 12:19:59 UTC
I've found some code defects in MultiTabContainer.java

- whenever a tab is selected, a listener also calls requestFocus()
  on it so that key events will go to the selected tab.  It does so
  only if the frame has focus.  It means the focus is not changed if
  tab is selected programmatically when the JFrame does not have focus.

- the second defect is that a newly selected tab can refuse to take
  focus, which is the default behavior of TopComponent
  [setRequestFocusEnabled(false)] and also the case of
  image/src/org/modules/image/ImageViewer.  requestFocus() is only
  a request after all.  This can be fixed by always setting the
  focus to the root pane first before calling requestFocus() on
  the newly selected tab

I attach a patch against release31 which should fix these two defects
Comment 7 _ ttran 2001-01-11 12:20:59 UTC
Created attachment 444 [details]
patch to fix the bug in release31
Comment 8 _ ttran 2001-01-16 14:50:59 UTC
I've committed my patch in release31.  The bug is left open because I'm not sure
if I managed to fix all situations when the wrong behavior happens
Comment 9 Jan Zajicek 2001-01-23 09:28:59 UTC
Automated change of version from Other to Dev.
Comment 10 Jan Chalupa 2001-03-12 09:32:56 UTC
Version: 'Dev' -> 3.2
Comment 11 Miloslav Metelka 2001-03-30 10:41:55 UTC
*** Issue 10474 has been marked as a duplicate of this issue. ***
Comment 12 Miloslav Metelka 2001-03-30 10:50:36 UTC
I have raised priority of this bug to P2. I like to use MDI but it seems that it
happens even more frequently with MDI and it is very annoying.
Comment 13 David Konecny 2001-04-02 17:03:38 UTC
Created attachment 944 [details]
This log file describes the focus problem
Comment 14 David Konecny 2001-04-03 14:27:02 UTC
Created attachment 963 [details]
logs of focus problem for 3.2 build19
Comment 15 David Konecny 2001-04-05 13:17:06 UTC
Created attachment 1008 [details]
ide.zip containing the latest log (created with maybe 10 days old build)
Comment 16 David Konecny 2001-04-18 15:50:11 UTC
*** Issue 9333 has been marked as a duplicate of this issue. ***
Comment 17 David Simonek 2001-04-18 16:06:41 UTC
Hopefully fixed. I tried all reproduction cases and also David Konecny's
reproductible case and they all seem working now.
Fix itself is in DefaultContainerImpl and checks AWT events for "strange"
FOCUS_GAINED events and tries to pair them with proper FOCUS_LOST events.
Comment 18 David Simonek 2001-04-19 12:58:14 UTC
OPEN_IN_3.2
Comment 19 David Konecny 2001-04-25 08:17:06 UTC
*** Issue 11723 has been marked as a duplicate of this issue. ***
Comment 20 David Konecny 2001-05-02 14:32:59 UTC
*** Issue 8990 has been marked as a duplicate of this issue. ***
Comment 21 Jan Chalupa 2001-05-05 20:40:18 UTC
Target milestone -> 3.3
Removing the OPEN_IN_3.2 keyword.
Comment 22 David Konecny 2001-07-13 08:19:11 UTC
*** Issue 13572 has been marked as a duplicate of this issue. ***
Comment 23 grk 2001-07-19 17:42:51 UTC
I'm confused - is this supposedly fixed?  Its still broken for me on
both 3.2 bld 39 as well as latest nightly.  All using jdk1.3.1, rh7.1,
gnome1.4, sawfish.

Its the same symptom - the selected tab in the editor window refuses
to accept key strokes, sometimes the key strokes go to another window
and sometimes they just disappear.

If there is a fix, please state it clearly.

This is the most annoying of bugs!
Comment 24 David Konecny 2001-08-01 08:16:54 UTC
*** Issue 14080 has been marked as a duplicate of this issue. ***
Comment 25 David Konecny 2001-08-01 08:22:41 UTC
Just yesterday it happened to me again. And as it is written in the 
last duplicate issue 14080, I was not able to get focus to the 
component which seems that has focus. The only way to get the focus 
there was to close the file and reopen it.
Comment 26 David Konecny 2001-08-03 15:52:16 UTC
I've been using Release32 for month or two and everything worked fine. 
 I've never seen the focus problem again. Last week I've upgraded to 
latest Dev build (and I'm upgrading IDE twice a week) and must say 
that I have this problem quite often now. At least 5-7 times during 
the last few days. Usually I must switch the worskpaces to get rid of 
it. Nothing else helps.
Comment 27 David Simonek 2001-09-09 17:21:36 UTC
Please, do you have any at least a little reproductible scenario? I've
fixed this bug and it should be fixed. Maybe my fix didn't catch all
occurences of the bug, please specify resproductible scenario! I don't
a free month for trying to reproduce. Thanks.
Comment 28 David Simonek 2001-09-09 17:23:53 UTC
please reopen with steps to reproduce.
Comment 29 Jan Zajicek 2001-09-14 12:33:16 UTC
Dafe, I don't think that it is fixed. It happens to me again. Of
course that I cannot reproduce it. But the fact, that it happens to
the people recently tell us that the bug persist or is back again. So
better to keep this as open issue. Do you think so?
Comment 30 Jan Pichert 2001-09-14 12:46:16 UTC
1. irreproducible - if selected window (w1) is not receiving key 
strokes
2. click on tab of previously opened editor window (w2)
3. click back to tab of the window that was not receiving the key 
strokes (w1)
4. focus remains on the (w2) where it was last edited, but w1 is 
showing
5. type into w1
6. w2 is being edited and the tab has a * to indicate that it is 
being edited
Comment 31 Petr Nejedly 2001-09-14 13:13:13 UTC
Which build did it happen to you the last time?
On 2001/09/07 (just a week ago) I've committed a change to the
org.openide.text.CloneableEditor.java reducing some inner classes
and also removing one very strange thing:
There was a FocusEvent forwarded, but the instance of the FocusEvent
was cached and sent even to different components than the component
against which it was created.
Now it creates new FocusEvent for each case (which is rare enough
that it doesn't deserve caching).

Build from Monday 2001/09/10 should contain these bits, so if you're
still able to reproduce it with this or later build, then it wasn't
the cause, otherwise mark this as fixed.
Comment 32 David Simonek 2001-10-03 15:38:59 UTC
updating subcomponent to window system
Comment 33 _ ttran 2001-10-23 10:29:03 UTC
this is a hard issue (see the numerous comments).  OTOH it seems that
the bug occurs very rarely now.  Lowered prio to P3 but kept this
issue open
Comment 34 David Konecny 2001-10-31 13:38:52 UTC
I would consider closing of this issue for 3.3. We have fixed a few 
causes of this problem and so hopefully it will not appear again. I 
personally did not see it for at least month.
Comment 35 _ ttran 2001-11-02 07:32:54 UTC
I agreed with David K => FIXED
Comment 36 Richard Bordoli 2001-11-19 16:21:53 UTC
I do not believe this issue has been resolved.  I have never stopped 
getting this problem.  Even with 3.3beta4 which I tried today.

My environment:
- Windows 2000 SP2
- JDK 1.3.1
- I run MDI (not sure if relevant to this issue)

To reproduce:
- Have half a dozen or so sources files open
- Introduce a deliberate compilation bug in 1 of the files
- start editing another file
- cause files to be compiled
- double click on error report in output window to bring up the 
compilational error
- start typing.... at this point if you have not encountered the bug 
then the chars will of course be going into the file with 
compilational errors... if you you have hit the bug then you are 
looking at the eroneous file but the characters are being sent to the 
last file you were editing before hitting compile.....

... this error does not always happen.. must be some form of 
timing/event racing condition.  Sometimes in the above scenario the 
typing is going to the file you *WERE* editing rather than the file 
that now has focus.  Clicking from tab to tab *DOES NOT* restore 
correct behaviour.  To restore correct behaviour you have to do one 
of the following:

- Close all open files and re-open using error report.  This seems to 
work about 50% of the time, but certainly not always...

- Minimize the whole IDE.  Restore IDE.  This nearly always works but 
don't think it is 100%

Very weird... and very annoying... is no one else seeing this problem 
since the issue was closed ?

-Richard.
Comment 37 _ ttran 2001-11-25 12:46:13 UTC
I'll find some time to look at this issue again.  Yes, I want to get
rid of it but you already know that this is a really hard problem :-(
Comment 38 ivan 2001-11-26 21:29:08 UTC
Some more tidbits of information.
This is not a problem in NB because I've seen it happen in non-NB
based applications, for example in a window with two terminalemulator
components in it. You can move the focus from one sub-component
to another and back, then if you have a dialog, sometimes the
focus gets stuck in one of the termulators. When this happens
you can move the focus between windows, but not between two
components in the same window.

I've looked through the sun bug database but haven't found any 
similar symptoms so am currently asking around. 

it seems to happen everywhere:
	OS: NT, solaris
window mgr: mwm, gnome/sawfish, windows
       jdk: 1.3.X, 1.4 (I just checked).
Comment 39 Jan Chalupa 2001-11-27 11:51:59 UTC
Target milestone -> 3.3.1.
Comment 40 Jan Chalupa 2001-11-27 11:55:41 UTC
Target milestone -> 3.3.1.
Comment 41 Søren Neigaard 2001-11-27 18:59:10 UTC
If you want to know, I have this problem too. I'm having a hard time
finding a patter too, but it sounds just like what Richard Bordoli
describes.

I'm running Forte CE 3.0 on Blackdown JDK 1.3.1 ontop of Mandrake
Linux. I run a lot of other Java apps. that uses tabs on the JVM too,
and they dont have this problem, so I can't really agree with Ivan
Soleimanipour  here.
Comment 42 _ ttran 2002-01-04 14:20:05 UTC
*** Issue 19018 has been marked as a duplicate of this issue. ***
Comment 43 Jan Chalupa 2002-01-11 14:01:57 UTC
Target milestone -> 3.4
Comment 44 Jan Chalupa 2002-01-11 14:05:28 UTC
Target milestone -> 3.4
Comment 45 Jan Chalupa 2002-01-11 14:07:04 UTC
Target milestone -> 3.4
Comment 46 Jan Chalupa 2002-01-11 14:10:27 UTC
Target milestone -> 3.4
Comment 47 Tracy Boehrer 2002-01-12 02:55:17 UTC
I too am having this problem and am dissapointed that the target has 
been moved to 3.4.  The problem is so annoying that I find it almost 
unbearable.  I would prefer to use Netbeans, but find the annoyance 
counter-productive.

I have the problem at least 6-7 times a day.  But related to this, 
and much more frequent, is the temporary loss of the caret.  I can 
reproduce the loss of a caret almost at will; simply changing focus 
to another application, then back to Netbeans will usually result in 
no caret being visible.  Changing focus to another app, then back 
usually corrects it.  Or simply selecting another tab, and back the 
original will also correct it.

I am running on Windows XP and JDK 1.3.1_02.
Comment 48 Peter Zavadsky 2002-01-21 14:58:02 UTC
Please have a look at issue #18859. It could have the same cause of
the  problem. There is also a suggested patch, so you could try it
out, maybe it coudl solve also this issue.
Comment 49 Richard R. Brandt 2002-01-22 18:23:48 UTC
I am having this problem as well.  How could this be an issue with 
windows?  I havn't seen it with any other IDE.

-The Big R
Comment 50 Tracy Boehrer 2002-01-25 16:06:04 UTC
I have some additional info on this bug:  If I run in SDI mode, 
instead of MDI, the problem is much less severe.  In fact, since 
running in SDI, I haven't had input go into another pane at all.  
Usually once, occassionaly twice, a day there will be no input 
allowed at all, but switching tabs (and back again) fixes that.

The only side effect I've noticed is that after switching to another 
application, and returning to Netbeans, there is often a 2-3 second 
delay for the editor to repaint.  It's totally blank until the 
repaint happens.  This didn't happen under MDI.
Comment 51 Martin Roskanin 2002-02-04 09:17:49 UTC
*** Issue 20088 has been marked as a duplicate of this issue. ***
Comment 52 Miloslav Metelka 2002-02-04 10:07:34 UTC
*** Issue 20088 has been marked as a duplicate of this issue. ***
Comment 53 Jan Lahoda 2002-03-07 15:48:11 UTC
A few days ago, new bug against editor was introduced. I asked some
questions to find out whether it is duplicate of this bug. My
conclusion is that it is. Please look on the questions and answers in
the bug - some are interesting. The new bug is here:
http://developer.java.sun.com/developer/bugParade/bugs/4645408.html

The main idea is that the user can not write into editor at all (as
was mentioned somewhere above). This happens to me sometimes. I have
not seen writting into another pane for a long time, only this "focus
lost".
On JDK1.3.x, it helps (100% for me) to switch workspaces (inside IDE).
On JDK1.4, sometimes happened to me that it did not help. The new user
problem is very similar.

I am proposing this attempt to find the bug:
1. Add some debug code (for focus gained, focus lost, and so on) and
print logs to IDE.log
2. Let it is enabled on property (for example:
-Dnetbeans.windows.focus=???)
3. Everybody who will want to help, will have this enabled (me on the
first place).
4. When this will happen to someone, relevant part of ide.log will be
attached into this bug. I hope we will be able to track the issue in a
few steps.

I know this is going to be hard work and will be time-consuming, but
this bug is 2 years old and is realy annoying.
Comment 54 Jan Chalupa 2002-04-10 10:03:26 UTC
Known, but unreproducible. Fix unknown. Requesting waiver for FFJ 4.0.
Comment 55 Jan Chalupa 2002-05-02 10:29:53 UTC
Waiver approved.
Comment 56 Marek Grummich 2002-07-22 08:31:39 UTC
Target milestone was changed from '3.4' to TBD.
Comment 57 Marek Grummich 2002-07-22 08:38:17 UTC
Target milestone was changed from '3.4' to TBD.
Comment 58 Marek Grummich 2002-07-22 08:53:52 UTC
Target milestone was changed from '3.4' to TBD.
Comment 59 Marek Grummich 2002-07-22 09:00:07 UTC
Target milestone was changed from '3.4' to TBD.
Comment 60 Marek Grummich 2002-07-22 09:00:27 UTC
Target milestone was changed from '3.4' to TBD.
Comment 61 Marek Grummich 2002-07-22 09:04:09 UTC
Target milestone was changed from '3.4' to TBD.
Comment 62 Marek Grummich 2002-07-22 09:05:30 UTC
Set terget milestone to TBD
Comment 63 Marek Grummich 2002-07-22 09:09:12 UTC
Set terget milestone to TBD
Comment 64 Jaroslav Tulach 2002-07-26 07:58:06 UTC
This bug is reported in version <= 3.4dev and still not fixed. Due to that it
forbids the release candidate for 3.4 to be promoted. Are you aware of that and
are you intensively working on the fix? If not, you should consider some
corrective action.
Comment 65 _ ttran 2002-07-26 14:04:13 UTC
> This bug is reported in version <= 3.4dev and still not fixed. Due
> to that it forbids the release candidate for 3.4 to be promoted. Are
> you aware of that 

no I am not aware of that.  Who said that this bug prevented the RC to
be promoted?  Arguments please
Comment 66 Jaroslav Tulach 2002-07-29 09:47:20 UTC
Hi, these issues block the 3.4 release. It has been suggested on nbdev that
those that are not going to be fixed for 3.4 FCS (waivers) change the target
milestone to "future" or "4.0". I'd like to suggest you to do so, if you and
your reporter agree on that.
Comment 67 _ ttran 2002-07-30 21:35:19 UTC
attached 3.4_WAIVER and asking for 3.4 waiver.  Justification:

very old bug, believed to still happen to some users but
irreproducible.  It also seems that this bug has become a sort of
umbrella bug to attach all kinds of focus-/editing-related problems.
There can be various causes of this bug.  We have fixed quite a few of
 them but there are probably more to be found and fixed.
Comment 68 Patrick Keegan 2002-07-30 21:46:16 UTC
waiver approved for 3.4
Comment 69 iformanek 2002-07-31 10:15:39 UTC
I agree with the waiver
Comment 70 _ ttran 2003-01-28 12:13:35 UTC
I am closing this bug.  Reason: the bug is caused by calling Swing
focus -related code from outside AWT event dispatcher thread
(violating Swing thread rule).  We have fixed many cases of this
violation we don't hear of users reporting this problem for a long time.

If it happens again, please file a separate bug and refer to this one.
 Don't reopen this bug, it has become a sort of umbrella bug and we
don't want to have one bug report to cover all instances of "the IDE
does not work".
Comment 71 Marian Mirilovic 2003-01-28 12:43:38 UTC
verified
Comment 72 Quality Engineering 2003-07-01 16:22:01 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.
Comment 73 Quality Engineering 2008-12-23 14:25:49 UTC
This issue had *9 votes* before move to platform component