Created attachment 161607 [details]
Possible solution

ExplorerActionsImpl uses a background thread to determine the enabled state of its actions. The background thread calls ExplorerActionsImpl.BaseAction.toEnabled(boolean) to set the target state from the background thread and then queues up a call on the EventQueue to be run on the EDT to call ExplorerActionsImpl.BaseAction.syncEnable() which calls setEnabled if toEnable is non-null.

However, since the check for toEnable != null, the use of toEnable in the call to setEnabled, and the set of toEnable = null are all on separate lines there is the possibility that another call to toEnabled(boolean) will set toEnable after the call to setEnabled but before it is reset to null. The end result is that if the new value of toEnable was different from the one being acted upon, the action may end up in the wrong state.

One solution (patch attached) is to use an AtomicInteger to get the value of toEnable and set it to null (or NO_CHANGE) atomically, thus avoiding the race condition.

I don't have a reproducible case in the NetBeans IDE, but we encountered this in our custom application using the NetBeans platform. The attached patch solved the issue in our case.