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.
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 ..
Second thread-dump points to PasteAction (AWT-thread) ?
Fixed in [trunk]
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.
Pavel, please put here the steps, also if it is on windows or solaris.
Comment 16Marian 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!
Fixed in [trunk] (second part)
Note: It is just a workaround which resembles older
pendingNodeActivator hack, needs to be investigated deeper see issue
Comment 18Marian Mirilovic
2003-01-15 13:12:12 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?
One more thing. What is meant by frame 'activated'? Is this some
kind of NetBeans activation or is this
Trying to find how a Frame can be activated but not focused, and is
that an error?
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