Bug 12520 - TopComponent.getActivatedNodes() returns wrong nodes for context menu actions
TopComponent.getActivatedNodes() returns wrong nodes for context menu actions
Status: CLOSED FIXED
Product: platform
Classification: Unclassified
Component: -- Other --
3.x
Sun Solaris
: P2 (vote)
: 3.x
Assigned To: David Strupl
issues@platform
: FOCUS
: 12245 12607 13800 13952 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2001-05-31 00:31 UTC by Sophie Deng
Modified: 2008-12-22 19:39 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sophie Deng 2001-05-31 00:31:06 UTC
This bug is on Solaris and occurs only when the Windows behavior is set to
"Click in Window to Make Active". To reproduce the bug:

1. Mount a directory
2. Create two new files, f1 and f2.
3. Multi-select both files and Open them in Editor 
4. Click on the Editor window so it gets focus, type some text in the f2,
   and hilight the text.
5. Move the cursor to Explorer and "right click" on the hilighted nodes
  (they are still f1 and f2 that we selected in step 3).
6. Popup menu appears in Explorer, perform cut. Instead of cuting f1&f2,
   the action cuts the text of f2 in the Editor.

This test case demostrates that the getActivatedNodes() returns the nodes that 
have the Window focus, instead of the nodes that are selected for the context
menu. This is different to the default windows (CDE's) behavior on Solaris.  My
module implements a bunch of actions which extend NodeAction. Since NodeAction
is performed on the getActivatedNodes(), I see this kind of problems in several
of my actions, I need the method to return the right set of nodes for not only
the menu/toolbar actions but also the context(popup) menu actions.
Comment 1 Sophie Deng 2001-06-01 16:35:32 UTC
We need this to be fixed in 3.2.1 for Pilsen release.
Comment 2 mslama 2001-06-06 11:24:03 UTC
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.)
Comment 3 Ann Sunhachawee 2001-06-07 22:49:43 UTC
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. 
Comment 4 Jan Zajicek 2001-06-08 09:41:27 UTC
*** Issue 12607 has been marked as a duplicate of this issue. ***
Comment 5 mslama 2001-06-08 09:46:25 UTC
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. 
Comment 6 mslama 2001-06-08 09:47:39 UTC
I reassign to Dafe
Comment 7 Jesse Glick 2001-06-11 11:34:59 UTC
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.
Comment 8 David Simonek 2001-06-11 11:55:11 UTC
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.
Comment 9 Sophie Deng 2001-06-15 17:56:58 UTC
Any update? Will I get the fix in NB 3.2.1?
Comment 10 Jaroslav Tulach 2001-06-18 08:37:42 UTC
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...


Comment 11 David Simonek 2001-06-18 09:32:49 UTC
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
Comment 12 Sophie Deng 2001-06-19 01:18:32 UTC
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.
Comment 13 Jaroslav Tulach 2001-06-19 18:42:05 UTC
David, can you disable the popup when BeanTreeView is not in focused window?
Comment 14 David Strupl 2001-06-20 15:17:00 UTC
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.
Comment 15 Sophie Deng 2001-06-21 00:06:25 UTC
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'.
Comment 16 David Strupl 2001-06-26 17:18:42 UTC
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?
Comment 17 mslama 2001-07-27 08:17:51 UTC
*** Issue 13800 has been marked as a duplicate of this issue. ***
Comment 18 Jan Zajicek 2001-07-27 13:45:59 UTC
*** Issue 13952 has been marked as a duplicate of this issue. ***
Comment 19 David Strupl 2001-08-07 13:09:51 UTC
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.
Comment 20 David Strupl 2001-09-05 14:00:59 UTC
*** Issue 12245 has been marked as a duplicate of this issue. ***
Comment 21 Marian Mirilovic 2001-12-13 09:53:38 UTC
verified in [nb](3.3)
Comment 22 _ ttran 2002-04-05 12:17:46 UTC
David's fix for this issue created bug 20887.  I am going to try a
different approach which would fix both bugs.
Comment 23 Quality Engineering 2003-07-01 16:44:02 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.
Comment 24 Jesse Glick 2003-08-29 19:14:41 UTC
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...


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo