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.
It is possible that a modal dialog that is on it's way down will bring down a subsequent dialog prematurely. scenario: In sunstudio the AttachDebugger action brings up a modal attach dialog which is managed by debuggercore (class ConnectAction). Choosing a target process and pressing OK will start the debugger engine which in turn puts up it's own dialog before the first one has completely gone away. However, as soon as the attach dialog goes away it prematurely brings down the second dialog with it. Looking at the code for DialogDisplayerImpl.createDialog() it's not hard to see why. When the second dialog is being "created" NbPresenter.currentModalDialog is still non-null, in which case the second dialog becomes it's child. This depends on whether the first dialog is a leaf. The debuggercore Connect dialog is not a leaf so the second dialog will become it's child. Then when the dialog pointed by NbPresenter.currentModalDialog goes away it will take it's child with it. Looking at the code for debuggercore there is ConnectListener.actionPerformed() which first calls ok() on the client and then brings down the attach dialog. The ok call to the client is what sets the attach in motion and is where the second dialog is created as a child of the attach dialog. Then actionPerformed() disposes the attach dialog and any of it's children. At first blush one might be tempted to say that debuggercore should dispose the dialog first and then call ok() on the client, or maybe not even dispose the dialog itself but let it pop out of it's nested event loop and only then call the ok() on the client. Also debuggercores Attach dialog may declare itself as a leaf which would also solve this problem. However, the design of DialogDisplayerImpl.createDialog() makes the assumption that dialogs created by modal dialogs are invariably their children. This may be the case, for example, when you get a cascade of deeper, more expert, dialogs like often happens on Windows. But the OK button seems to prove the exception to this assumption causing surprising behaviour. A more philosophical way to look at this: who is responsible for postponing the side-effect of OK until it's containing dialog is gone? I'm currently working around this by having the call to (my) ok() postpone the actual attach action via an invokeLater.
DialogDesciptor has a way how to solve this problem, if I understand the problem correctly. DialogDescriptor has a field 'leaf' (http://bits.netbeans.org/dev/javadoc/org-openide-dialogs/org/openide/DialogDescriptor.html#setLeaf(boolean)) which was designed to help in such cases: The application has the main window W, once new dialog D1 is opened then W will be parent of D1. And then if a next dialog D2 is opened, D1 is parent of D2. i.e. W<-D1<-D2. When an user closes D1, D2 is closed as well because its parent disappears. That's the case why 'leaf' field is there. Construct D1 with leaf=true in its constructor or use DD.setLeaf(true) and D1 cannot become as parent of other dialog, e.g. W<-D1 and W<-D2. In the end, both dialog can close independent each other. Hope it helps, -jiri
So you're saying debuggercores attach dialog should mark itself as a leaf? But a dialog may not be able to know if it's a leaf or not. For example, the debuggercore Attach and NewBreakpoint dialogs host panels provided by various debugger implementations. These panels may have actions which pop up more dialogs.
I do understand that but the proposed pattern with setLeaf(true) has been applied to such conflicting dialogs up to now. I guess it cannot cover all cases perfectly, it's one of possible workarounds. Perhaps, a ideal solution would be new DD method like setAsTopDialog() which you could apply on your dialog to avoid unintentional closing of it. If you agree I'm going to change this issue to RFE of DialogDescriptor API for that method.
Btw. the reason for DD.setLeaf(boolean) method was issue 53525 which came with this problem the first time.
IZ 53525 is the exact same problem I've described here. Leafness is not a property one should have to assign. It's a derivative propery and should mean "do I have any children". (I know with Nodes it's a bit more complicated but I don't think dialogs do what Nodes do) When swing/AWT dialogs are created they get assigned an owner. Why is it that that relationship not being used to determine leafness? For that matter, shouldn't a correct swing-level owner relationship bring down D2 when D1 goes away? Wy does NB need to do something extra? It sees to me that the NB dialog code establishes an incorrect parent-child relationship between unrelated dialogs. Instead of "not doing that" isLeaf is a workaround that says ignore that incorrect automatically generated parent-child relationship.
Need to new constructor/method in DialogDescriptor API to allow to specify owner of dialog.
Not in current plan to fix it
NetBeans.org Migration: changing resolution from LATER to WONTFIX