Community
Participate
Working Groups
3.2 RC5 If the enablement logic of a contributed action (object contribution or viewer contribution) depends on some state of the selected object, and some of the actions can affect that state, then it's possible to get incorrect enablement showing in the context menu if the user pops up the menu twice without the selection changing in between. For example, imagine that the Close Project action was contributed declaratively: - select an open project - pop up the menu - Close Project is enabled - select Close Project - the project gets closed - pop up the menu again - Close Project is still enabled, even though the logic says it should be disabled Recommendation: - call selectionChanged on the PluginActions when the menu is shown, not just when the selection changes. getSite().registerContextMenu(viewer, contextMenuManager); // after registering the menu manager, add a menu listener // that will go through an force the enablement of contributed // actions to be updated contextMenuManager.addMenuListener(new IMenuListener() { public void menuAboutToShow(IMenuManager manager) { ISelection selection = viewer.getSelection(); IContributionItem[] items = manager.getItems(); for (int i = 0; i < items.length; i++) { IContributionItem item = items[i]; if (item instanceof ActionContributionItem) { IAction action = ((ActionContributionItem) item).getAction(); if (action instanceof PluginAction) { ((PluginAction) action).selectionChanged(selection); } } } }
This is another example where computing enablement on-demand (rather than requiring selection and other kinds of listeners to be hooked for any state that can affect enablement) would be simpler. That's effectively what this workaround achieves, but unfortunately it requires an internal reference to PluginAction.
Note to self: corresponding Jazz bug is #7454.
In 3.2, it appears this is only an issue for viewer contributions. Object contributions are added each time the menu is shown, and their selection is updated.
The suggested workaround is no good. It can cause problems for object contributions that use adapters. Normally the workbench passes the converted selection, but the workaround does not. A better workaround is: getSite().registerContextMenu(viewer, contextMenuManager); // after registering the menu manager, add a menu listener // that will fire a selection changed event, in order // to update the selection in contributed actions contextMenuManager.addMenuListener(new IMenuListener() { public void menuAboutToShow(IMenuManager manager) { viewer.setSelection(viewer.getSelection()); }
See also bug 48326.
Assigning to component owner PW
I'll take a look at this in M3 (hopefully, or M4) PW
I guess M6 it is :-) PW
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
