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.
| Summary: | IDE starts changing focus in infinite loop after restart | ||
|---|---|---|---|
| Product: | platform | Reporter: | Jiri Skrivanek <jskrivanek> |
| Component: | Window System | Assignee: | Peter Zavadsky <pzavadsky> |
| Status: | VERIFIED FIXED | ||
| Severity: | blocker | CC: | dnoyeb, mmirilovic, mslama, tpavek |
| Priority: | P1 | Keywords: | FOCUS |
| Version: | 3.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: |
Thread dump after restart while changing focus
Previous thread dump from deadlocked IDE. Thread dump from build 20030110 when changing focus Another thread dump from build 20030110. |
||
|
Description
Jiri Skrivanek
2003-01-10 10:14:24 UTC
Created attachment 8520 [details]
Thread dump after restart while changing focus
Created attachment 8521 [details]
Previous thread dump from deadlocked IDE.
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 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) ? It was made on build which contained perf issue #29927. Please try to reproduce on current build. 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. Pleae, put there also new thread dump, the code was changed so I can see where the problem could be, thanks. Created attachment 8542 [details]
Thread dump from build 20030110 when changing focus
Created attachment 8543 [details]
Another thread dump from build 20030110.
Those last thread dumps don't say anything, there is no hanging up. AWT threads are runnable, so where is the problem? 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. Reopened, the patch is not compilable with jdk1.3, will try to find solution. Fixed in [trunk] core/../windows/frames/TopFrameTypeImpl.java 1.24 The last fix should be checked once more time. Still there in 20030114 if you open a form... Pavel, please put here the steps, also if it is on windows or solaris. Thanks 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) 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. verified in [nb_dev](20030115) 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. 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. 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). |