Bug 162241 - [Contributions] (regression) Object contribution not enabled by default
Summary: [Contributions] (regression) Object contribution not enabled by default
Status: ASSIGNED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform UI Triaged CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-25 12:58 EDT by Nick Edgar CLA
Modified: 2019-09-06 16:12 EDT (History)
0 users

See Also:


Attachments
Zip of test plug-in (7.13 KB, application/zip)
2006-10-25 16:17 EDT, Nick Edgar CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Edgar CLA 2006-10-25 12:58:57 EDT
3.2

We have an object contribution whose selectionChanged method simply hangs onto the selection, but does not change its enabled state.
Previously (I believe as recently as the 3.2 release candidates), this action would always be enabled as long as it met the selection criteria (right kind of object and size) specified in the plugin.xml.  Now it's disabled by default, and remains disabled since we don't change the enablement in code.

I believe this is due to the following optimization in SelectionEnabler:
		// Optimize it.
		if (mode == UNKNOWN) {
			return false;
		}

Since the action delegate is in the same plugin as the view (and its plugin is therefore activated), it gets instantiated fairly early when reading the extension (set a breakpoint in its constructor to see this) and the corresponding PluginAction gets its enablement updated with false.  This doesn't get changed later.
Comment 1 Nick Edgar CLA 2006-10-25 16:17:04 EDT
Created attachment 52702 [details]
Zip of test plug-in

The following test plug-in shows the problem.
Steps:
- show the SampleView view
- select one of the items
- bring up the context menu
- the Test Action item is disabled
- if you uncomment the setEnabled(true) line in TestAction, it's enabled
Comment 2 Paul Webster CLA 2007-04-05 19:05:37 EDT
Assigning to component owner
PW
Comment 3 Paul Webster CLA 2007-04-26 20:59:14 EDT
The mode is unknown in your example because it won't accept 1+ as enablesFor.

When mode==UNKNOWN it just means it wasn't able to parse the enablesFor element.  If the attribute is not there at all, it gets set to ANY_NUMBER.

I'd prefer to leave the behaviour (as it indicates a problem with the action definition).  But we could set the mode to ANY_NUMBER by default and just log the parsing error.

PW
Comment 4 Nick Edgar CLA 2007-04-30 17:06:03 EDT
Wow, I guess I should have checked the schema.  So I need to use '+' instead of '1+'.  We could definitely improve the error checking / reporting here.  A log entry would be good (e.g. using the RegistryReader.logError helpers).
Comment 5 Nick Edgar CLA 2007-04-30 17:13:18 EDT
Actually, for object contributions, enablesFor="+" is redundant.
Still useful for the other kinds of contribution though.
Comment 6 Eclipse Webmaster CLA 2019-09-06 16:12:32 EDT
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.