Bug 208893

We found an issue with the integration of Netbeans 7.1 RCP in our application (previously we were using Netbeans 6.9 RCP). 

There is an issue with the ExplorerActionsImpl (and its private class ActionStateUpdater), which is confined to the actions within an explorer context. The ActionStateUpdater is attached to the ExplorerManager for the explorer context as a property change listener and updates the status of the cut, copy, paste and delete actions in response to any changes, e.g. when displaying the actions in a menu when the explorer gets focus etc.  

The ActionStateUpdater does this by setting the actions as disabled then running the class RequestProcessor.Task() to update the action statuses, so the actions are enabled asynchronously with the display of the actions in the menu.

The current implementation has caused issues with our automation tools as they expect keyboard actions and menu displays to be single threaded and the menu fully populated and active once the main thread has finished. 

Would it be possible to parametrize this behaviour so that it can be disabled, for automation testing, this will allow us to still give our end users the full benefits of what it brings without having to painfully code in suitable delays in the automation suite?