Created attachment 1851 [details]
Thread dump of this bug

phrebejk is the "owner" of Nodes subsystem

Let me know if you want me to investigate, I don't have any P2s at the
moment...

If you'd like, you're welcome.
I'd take look at it but I'm taking some days off now.

Hints:
It is actually called 3 times in my case.
The problem of the first two seems to lay in
org.openide.awt.Actions.MenuBridge:457,
or in implementation of NodeAction:
                button.setEnabled (action.isEnabled ());
action.isEnabled drives one direct call to enable(), while
button.setEnabled() calls it indirectly through PropertyChangeEvent

Why does the Bridge react to changes of "enabled" property of the
component?

Adding Jesse to cc:
I thought you're already on cc, but realized you aren't.

OK, I can try to track it down.

Sure, if you want. I was investigating this bug and I think that the 
problem is the call to updateState( null ). In the four connect()
methods in org.openide.awt.Actions.

Jarda said that ot should be OK when the call is avoided. However
when I did it the IDE didn't started because of VCS module. This is
relatively easy to fix and is maybe already fixed.

The second problem is that after the change menus in main window 
sometimes become very small. I didn't have time to further investigate
this, but I think that some initialization in the menu items is not
called and the size of the component is not computed correctly.

I can confirm that NodeAction.enable(Node[]) is called way too often.
If you install a tools action and switch Explorer nodes, it is called
for every switch, even though the popup is not showing at all, and
nobody is actually calling isEnabled()! Probably it should (1) after
firing a change in PROP_ENABLED, stop calling enable(Node[[]) on
subsequent selection changes until someone next calls isEnabled(); (2)
keep a weak cache of the last node selection it actually checked and
not do anything if the enablement has already been computed for this
selection. addNotify() and removeNotify() seem to be called at
appropriate times, but this does not seem to help avoid calls to
enable(Node[]). CookieAction may need similar treatment. I am trying
to write a test suite for org.openide.util.actions.* to assist in
checking these things. My guess is that it is better to fix the
redundancy directly in the actions, rather than trying to make the
action bridges more complicated.

Issue #17196 has a proposed patch attached.

Would somebody (esp. Yarda or Petr N.) like to review the patch in
#17196? It seems to work well. I still need to check up on strange
problems with S-F10 (popup) and creating popups from the editor;
either file separate bugs if they exist without this patch, or figure
out what to do if this patch causes them.

Is it too late in the release cycle to make significant changes to
NodeAction do you think? Looking at what is actually called right now
when you have some actions installed (toolbars, menus, tools actions,
context actions), enable(Node[]) is really called too often. The patch
ensures it is only called once per node selection, and only called at
all when somebody is actually going to use the information. (E.g.
changing node selection should not do enablement checks on tools
actions that are not even showing!)

I will attach a mini module which installs some actions in typical
ways: a tools action (Node); main menu item (Cookie); context menu
(Cookie); toolbar presenter (Node). It shows you when isEnabled(),
enable(), addNotify(), and removeNotify() are called.

Created attachment 3236 [details]
Testing module JAR (installs actions and shows enablement)

Comment from Yarda: WeakListener could probably be used for the
listeners in CbSA and NA, which would perhaps simplify the code
(though I think with the same result).

Note the change in behavior of NA as far as PROP_ENABLED goes: with
the patch, if you call isEnabled() and it says true (e.g.), and you
have the focus listener turned on (addNotify() has been called), and
the node selection changes--it will now fire PROP_ENABLED but with a
new value of null. So anyone listening to changes will get a change
notification. However, the actual new value (true or false) will not
really be computed yet. So long as nobody calls isEnabled(), no more
PROP_ENABLED changes will be fired as the node selection continues to
change. I think this is acceptable; if you don't know what the new
value is, it cannot matter if it changes again before you ask. I did a
search thru nb_all and f4j_all looking for code using PROP_ENABLED or
"enabled" from NodeAction; in all cases I could find it simply checks
if a PROP_ENABLED is fired, and if so calls some refresh method, which
would then call isEnabled() and get the new value. Hypothetical code
which used the new value from the property change would find that it
is now null (but correctly written listeners will accept this and call
isEnabled() as a fallback, and so continue to work as before). Note
that PROP_ENABLED may now be fired when in fact the value did not
really change (because it is fired before this is known); I think this
is preferable to recomputing enablement too much, as most listeners
would just call e.g. JButton.setEnabled(...) which should do nothing
if called with the same value as it already has.

Fixed:

Actions.java 1.52
(CookieAction.java 1.18)
NodeAction.java 1.29

Verified.

Resolved for 3.4.x or earlier, no new info since then -> closing.