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: | TopComponent.getActivatedNodes() returns wrong nodes for context menu actions | ||
---|---|---|---|
Product: | platform | Reporter: | Sophie Deng <sdeng> |
Component: | -- Other -- | Assignee: | David Strupl <dstrupl> |
Status: | CLOSED FIXED | ||
Severity: | blocker | CC: | asunhachawee, jglick, jtulach, mslama, raccah |
Priority: | P2 | Keywords: | FOCUS |
Version: | 3.x | ||
Hardware: | Sun | ||
OS: | Solaris | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Sophie Deng
2001-05-31 00:31:06 UTC
We need this to be fixed in 3.2.1 for Pilsen release. The problem is specific only to Solaris, CDE window manager. In mentioned configuration right mouse click does NOT activate window. However selected nodes are set according to activated window/top component NOT according location of right mouse click. (So popup menu actions are using selected nodes of activated component which is NOT necessarily component where right mouse click was done.) Preferable solution is to find CDE configuration which activates window by right mouse click or avoids necessity to activate window by right mouse click. (Eg. focus follows mouse.) Actually, what Marek stated is not completely true. In this situation where the user right clicks on an object/window that is not active, the correct context menu for that object/window comes up and *not* the context menu for the objects selected in the active window. We cannot expect the user to use the proposed solution of changing their window focus preference. I would like to verify the behavior of other window managers (say on Linux), and then we can evaluate if this bug should be addressed. *** Issue 12607 has been marked as a duplicate of this issue. *** There are two things: Popup menu and selected nodes. Popup menu is displayed from clicked component/window BUT selected nodes are provided for activated component/window. Currently popup menu is displayed even if component/window is not activated. I reopen it. We try to solve it in IDE: Popup menu will not be displayed if component/window is not activated. I reassign to Dafe I will suggest once again that the global node selection be ignored when displaying popups and the window/nodes that the popup was actually activated on be passed directly to affected actions (requires API changes in e.g. NodeAction). Theoretically this would have the same behavior, practically it would avoid a host of bugs associated with poor window manager behavior...see a much older bug report I added comments to. Disabling the popup if the window has no focus is a workaround, not really a solution. Hm, ok, but I don't understand how to pass nodes directly? Rewrite NodeAction to get them directly, but how? Find topcomponent to which popup belongs and ask for selected nodes? I think I'll need help with implementation, it's more nodes and acions then window system. Any update? Will I get the fix in NB 3.2.1? Sophie, API changes in 3.2 release? You must be jokeing... Dafe, could a workaround be based in listening on Swing menu manager and when a menu is shown for a topcomponent, update the list of activated nodes for it? It is a bit late, the menu will redraw, but better than nothing... No, I wouldn't do that, this will lead to situation when activated nodes will differ from nodes on active window - this will produce another bunch of bugs which will say: "I have active editor window and all actions are done on explorer's active nodes". In short, I don't see a way how to fix it for 3.2.1 Sorry, I should have made it clear. No I am not expecting a fix, but a reasonable workaround for 3.2.1. How about the workaround that Marek suggested, i.e to disable popup if the window does not have focus? Is it doable? Thanks. David, can you disable the popup when BeanTreeView is not in focused window? I will try and let you know. But please keep in mind that this sounds risky: we can easily end up in state where the rigth click will not bring up the menu when it should. If the workaround is really risky, I will prefer that we don't implement it but just document it in the release note. This won't be just a TeamWare's problem though but every modules'. I have tried to put the following into TreeView.createPopup: java.awt.Window w = SwingUtilities.getWindowAncestor(TreeView.this); if ((w != null) && (w.hasFocus()) ... No luck (no popup ever). Nor following: Component c = TreeView.this; boolean haveFocus = false; while ((c != null) && (!c.hasFocus())) { c = c.getParent(); } if (haveFocus) ... Not only the fix sounded risky - I don't have one. Anyone has any suggestion? *** Issue 13800 has been marked as a duplicate of this issue. *** *** Issue 13952 has been marked as a duplicate of this issue. *** Ok. I have disabled the popup menu for non-active top components in the trunk. Please try it and report any problems you might encounter. This is just a workaround. If you think that the issue requires more radical API changes please fill in a request for ENH/TASK for openide/actions. If this request is made please specify target milestone to 4.0. Thanks. *** Issue 12245 has been marked as a duplicate of this issue. *** verified in [nb](3.3) David's fix for this issue created bug 20887. I am going to try a different approach which would fix both bugs. Resolved for 3.4.x or earlier, no new info since then -> closing. The underlying problem should have been fixed properly in NB 3.5, so I will revert this ugliness in TreeView in the trunk if nobody minds... |