Bug 29939 - IDE starts changing focus in infinite loop after restart
IDE starts changing focus in infinite loop after restart
Status: VERIFIED FIXED
Product: platform
Classification: Unclassified
Component: Window System
3.x
All All
: P1 (vote)
: 3.x
Assigned To: Peter Zavadsky
issues@platform
: FOCUS
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-01-10 10:14 UTC by Jiri Skrivanek
Modified: 2008-12-23 09:41 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Thread dump after restart while changing focus (9.57 KB, text/plain)
2003-01-10 10:16 UTC, Jiri Skrivanek
Details
Previous thread dump from deadlocked IDE. (10.93 KB, text/plain)
2003-01-10 10:18 UTC, Jiri Skrivanek
Details
Thread dump from build 20030110 when changing focus (6.38 KB, text/plain)
2003-01-13 08:28 UTC, Jiri Skrivanek
Details
Another thread dump from build 20030110. (8.08 KB, text/plain)
2003-01-13 08:35 UTC, Jiri Skrivanek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Skrivanek 2003-01-10 10:14:24 UTC
It happens in build 20030109-2209 on JDK1.4.1.
After some time of using IDE, it hanged (deadlock
while running automated jemmy test). Then I
restarted IDE and it came up and starts blinking.
It was changing focus between Explorer window and
Source Editor window. Attached is thread dump
taken while this was happening and thread dump
from previous deadlock.
Comment 1 Jiri Skrivanek 2003-01-10 10:16:12 UTC
Created attachment 8520 [details]
Thread dump after restart while changing focus
Comment 2 Jiri Skrivanek 2003-01-10 10:18:13 UTC
Created attachment 8521 [details]
Previous thread dump from deadlocked IDE.
Comment 3 Jiri Skrivanek 2003-01-10 10:21:21 UTC
Steps to reproduce:

- run ide
- switch to SDI
- close Source Editor
- open Source Editor for e.g. ColorPicker class
- shutdown IDE
- start IDE again
- it starts neverending show
Comment 4 Marian Mirilovic 2003-01-10 12:43:55 UTC
Jirka:
I am not able to reproduce it. I am using [nb_dev](200301100100),
[jdk1.4.1](01) & [jdk1.4.2](b12) without success. What JDK version do
you use ?

Steps I tried:
- run IDE with clear userdir
- from Setup Wizard switch to SDI mode
- close Source Editor (Welcome Screen opened as default)
- from popup menu push "Edit" , node ColorPicker
- restart IDE
-> IDE run again without any troubles, deadlocks, freezes ..

Peter:
Second thread-dump points to PasteAction (AWT-thread) ?
Comment 5 Peter Zavadsky 2003-01-10 14:23:53 UTC
It was made on build which contained perf issue #29927. Please try to
reproduce on current build.
Comment 6 Jiri Skrivanek 2003-01-13 07:57:02 UTC
I am able to reproduce it easy with build 200301100100 both on
Solaris, Gnome, JDK1.4.1(b21) and Windows2000, JDK1.4.1_01(b01).
Automated tests started to fail from continuos build 20030109-1822.
Comment 7 Peter Zavadsky 2003-01-13 08:10:27 UTC
Pleae, put there also new thread dump, the code was changed so I can
see where the problem could be, thanks.
Comment 8 Jiri Skrivanek 2003-01-13 08:28:14 UTC
Created attachment 8542 [details]
Thread dump from build 20030110 when changing focus
Comment 9 Jiri Skrivanek 2003-01-13 08:35:32 UTC
Created attachment 8543 [details]
Another thread dump from build 20030110.
Comment 10 Peter Zavadsky 2003-01-13 08:38:47 UTC
Those last thread dumps don't say anything, there is no hanging up.
AWT threads are runnable, so where is the problem?
Comment 11 Peter Zavadsky 2003-01-13 16:17:52 UTC
Fixed in [trunk]

core/../windows/frames/TopFrameTypeImpl.java 1.22

Note:
There is a problem frame can be in activated state but not focused
yet, if in this gap, another frame get activated and requests focus
(which is forced by winsys), it could happen they start to cycle,
since the focus request caused activation and vice versa. Thus the
operation when one frame is activated and requests focus, can't be
'overlapped' by the same operation of another frame.
Comment 12 Peter Zavadsky 2003-01-13 17:43:01 UTC
Reopened, the patch is not compilable with jdk1.3, will try to find
solution.
Comment 13 Peter Zavadsky 2003-01-13 18:01:54 UTC
Fixed in [trunk]

core/../windows/frames/TopFrameTypeImpl.java 1.24

The last fix should be checked once more time.
Comment 14 Tomas Pavek 2003-01-14 10:46:16 UTC
Still there in 20030114 if you open a form...
Comment 15 Peter Zavadsky 2003-01-14 12:54:37 UTC
Pavel, please put here the steps, also if it is on windows or solaris.
Thanks
Comment 16 Marian Mirilovic 2003-01-14 13:27:49 UTC
reproducible on Win2000, [nb-dev](20030114), [jdk1.4.2](b 12)

Steps to reproduce:
- run IDE with clear userdir
- switch to SDI mode (by Setup Wizard)
- close Source Editor window
- doubleclick on Colorpreview form file
-> Form Editr window and Source Editor window blinking and focusing! 
Comment 17 Peter Zavadsky 2003-01-14 19:00:45 UTC
Fixed in [trunk] (second part)

core/../windows/frames/DefaultContainerImpl.java 1.68


Note: It is just a workaround which resembles older
pendingNodeActivator hack, needs to be investigated deeper see issue
#30092.
Comment 18 Marian Mirilovic 2003-01-15 13:12:12 UTC
verified in [nb_dev](20030115)
Comment 19 dnoyeB 2003-03-31 20:25:29 UTC
I am working on issue #32436 so I need a little clarification.

Peter you say frame can be activated, but not yet focused.  Does this
mean frame activated, and then requested focus, but has yet to receive
it?  Or that it has yet to request focus?

Any why does the fix for a situation related to activation vs. focus,
not include anything that checks activation vs. focus?  Are their some
hidden relationships I can not see?

Thank you.
Comment 20 dnoyeB 2003-03-31 20:55:28 UTC
One more thing.  What is meant by frame 'activated'?  Is this some
kind of NetBeans activation or is this
java.awt.event.WindowEvent.WINDOW_ACTIVATED?

Trying to find how a Frame can be activated but not focused, and is
that an error?

Thanks again.
Comment 21 Peter Zavadsky 2003-04-07 08:34:16 UTC
Almost you are right.

Some things behind. When the frame is activated, we are assuring that
it gets focus (i.e it is passed to selected top component), so we are
requesting it explicitly. On the other hand if the frame (some comp in
it) gets focus, we are assuring the frame is selected (in the sense of
win sys - activated), the events seem not to come in fixed order. 

I don't remember all the detailed issues. I wondered it is done this
way, but current winsys impl is very complicated, and both of theses
'assuring flows' make also a couple of 'side effects', which I wasn't
able to understand very quickly, and was afraid to break them so late.
These flows were the problem the hack was put in.

The hack is an incarnation of former "pending node activator" hack (it
was present in DefaultContainerImpl), which was removed (it did also
another things).



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