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.
This was entered in bugtraq (4648042 see : http://developer.java.sun.com/developer/bugParade/bugs/4648042.html ) ============================================ Description FFJ40EE-EA #020301_1 jdk1.4.0, Solaris 5.8 window configuration MDI When "some" modules is first installed during the first start and the ide is started in MDI mode, then there are two types of corruption: 1. properties window is undocked and has size 0 or 2. the workspace is wrongly repainted e.g. when editor is opened Why this module doesn't come with his xml in {ide_home}/system/Modules and therefore is recognized as newly installed during the first start? Note, if ide is started in SDI first time and the switched into MDI or if the ide is killed and started again - everything is ok. Looks like there is some problem in ModuleInstall. We cannot trace it here because we haven't acces to your source code. Please evaluate this on your side. How to reproduce: 1.Install FFJ40EE EA with xxxxx developer modules. 2.Start ide first time (against fresh userdir) in MDI mode 3.Properties will be undocked or main MDI split will be blue and next opened editor is placed over explorer. Workaround Put proper com-sun-forte-st-ipe.xml into {ide_home}/system/Modules or delete solaris-native.jar before first start of FFJ40EE EA. Evaluation xxxxx@xxxxx 2002-03-06 Currently, the ifdef module xml file is not generated or installed and the problems are reproducible. When the ifdef xml file is added to the ide, the problems observed are no longer there. xxxxx@xxxxx Fri Mar 8 00:51:05 PST 2002 George and I have been looking at it today. We've reached the following conclusions so far: (*) The missing .xml file in system/Modules is not the culprit. The problem can be observed even with this file in place (*) We thought perhaps this was an issue of missing Solaris patches (which is often the case when you have Swing redrawing problems) but this problem has been observed on fully patched systems. Unfortunately the problem does not seem to be 100% reproducible, it happens Now And Then (tm). Here's my current hypothesis. Whenever you run into problem in Swing it's often because you've improperly accessed (or worse, modified) component state for visible components from any other thread than the AWT thread (the "event dispatching thread"). So I'm guessing some code is doing this at startup, which leaves the window system in a corrupted state which in turn results in the incorrect window bounds etc. which seems to lead to the various problems described in this bugreport. So I instrumented my Swing runtime to check that whenever a Component method is called, and the component is visible, the current thread had better be the event dispatch thread. And I found that this condition is violated! However, it doesn't seem to be violated by ifdef - it's by the Setup Wizard code. Here's some sample stacktraces that are printed out. I'm not sure if this is the bug - but it's certainly plausible (and in any case the below component access is illegal and needs to be fixed). ***** Swing called from non-AWT-EventQueue thread "Folder Instance Processor" java.lang.Exception: Stack trace at java.awt.Component.ensureEventThread(Component.java:5521) at javax.swing.JComponent.setEnabled(JComponent.java:1885) at javax.swing.AbstractButton.setEnabled(AbstractButton.java:1532) at org.openide.WizardDescriptor.updateState(WizardDescriptor.java:457) at org.netbeans.core.ui.SetupWizard$InitializedWizardDescriptor.updateState(SetupWizard.java:403) at org.openide.WizardDescriptor$Listener.stateChanged(WizardDescriptor.java:941) at org.netbeans.core.ui.WizardFolder$CompoundIterator.setIterators(WizardFolder.java:171) at org.netbeans.core.ui.SetupWizard.createInstance(SetupWizard.java:150) at org.openide.loaders.FolderInstance.defaultProcessObjects(FolderInstance.java:571) at org.openide.loaders.FolderInstance.access$100(FolderInstance.java:45) at org.openide.loaders.FolderInstance$2.run(FolderInstance.java:456) at org.openide.util.Task.run(Task.java:152) at org.openide.util.RequestProcessor$ProcessorThread.run(RequestProcessor.java:622) ***** Swing called from non-AWT-EventQueue thread "Folder Instance Processor" java.lang.Exception: Stack trace at java.awt.Component.ensureEventThread(Component.java:5521) at javax.swing.JComponent.disable(JComponent.java:2587) at java.awt.Component.enable(Component.java:817) at java.awt.Component.setEnabled(Component.java:782) at javax.swing.JComponent.setEnabled(JComponent.java:1890) at javax.swing.AbstractButton.setEnabled(AbstractButton.java:1532) at org.openide.WizardDescriptor.updateState(WizardDescriptor.java:458) at org.netbeans.core.ui.SetupWizard$InitializedWizardDescriptor.updateState(SetupWizard.java:403) at org.openide.WizardDescriptor$Listener.stateChanged(WizardDescriptor.java:941) at org.netbeans.core.ui.WizardFolder$CompoundIterator.setIterators(WizardFolder.java:171) at org.netbeans.core.ui.SetupWizard.createInstance(SetupWizard.java:150) at org.openide.loaders.FolderInstance.defaultProcessObjects(FolderInstance.java:571) at org.openide.loaders.FolderInstance.access$100(FolderInstance.java:45) at org.openide.loaders.FolderInstance$2.run(FolderInstance.java:456) at org.openide.util.Task.run(Task.java:152) at org.openide.util.RequestProcessor$ProcessorThread.run(RequestProcessor.java:622) What I'm going to do now is see if I can wrap this setup wizard into a SwingUtilities.invokeAndWait() and see if this fixes this bug. Of course, I can't be 100% confident since this bug only shows up intermittently - but since it usually triggers at least once in every five startups, if I can bring the IDE up 10 times without triggering it I'll feel better. Perhaps not justifiably so, since tweaking with invokeLater can (and will) change timings of things which might just hide this bug on my machine configuration... If anyone in Prague is looking at this and have some insights in what might be going on (not just with the Setup Wizard - with our module (look at the "ifdef" module in the closed source repository - in particular the module install class (IpeModule.java), the manifest.mf file, and the layer file (system.xml)) please let me know. One note about the line numbers in the above stack trace; I've been reproducing this with the -trunk-, not EA, so if the line numbers don't make sense, be sure to check the trunk sources. Eval: The problem seems to be following. There is loaded window sys before the Setup wizard comes up. And somtimes during the time due to some race condition is set mode for the Properties window (NbNodeOperation.Sheet source) in the intention is SDI mode, and when then is set in the wizard to MDI, it doesn't reset the default accordingly. I haven't find the solution up to now. Thought only problem is finding of node in updateTitle method of NbNodeOperation.Sheet, which was performed sometime before the Setup Wizard, but wasn't enough to by pass it. The problem is probably the fact the window sys is due some race condition somtimes already set when appears the Setup Wizard, probably not deterministic enough startup sequence. Or there could be a problem when setting the mode (SDI/MDI first time is not done the switching work) in Setup Wizard for the first time. Leaving for Dafe who knows more about it, and be back on Monday. But is seems the problem is in core.
accepting...
finally fixed (hopefully), reseting of winsys state is not done when no workspaces are loaded (during first start). WizardFolder now also correctly runs its tasks in AWT thread.
Created attachment 5072 [details] patch jar
Created attachment 5073 [details] textual diff
fixed
verified patch with FFJ(020307)
verified in [orion_CE](20020401) && [jdk1.3.1](03)/[jdk1.4](fcs)
Resolved for 3.4.x or earlier, no new info since then -> closing.