Basically I wanted to add a sub-element to a decorators extension as shown in the figure on the left. But... there was no sub-elements to add in the pop-up menu.
I have seen that problem a couple of times after I have started to use first 3.3M7 and now 3.3RC1, and this time I had the time to report the problem...
Only a few minutes ago, Mike Pawlowski fra IBM, answered the bug with the following answer:
The decorators schema (/org.eclipse.ui/schema/decorators.exsd)
uses the common expression schema (/org.eclipse.ui/schema/commonExpression.exsd).
In the latter schema, the enablement's grammar is defined as follows:
<!--ELEMENT enablement (and | or | not | objectClass | objectState | pluginState | systemProperty)-->
As a result, the enablement element is only allowed one child. From your screenshot it appears it already has a child.
There was a new feature implemented in the Extensions section that populates the context menu with extension elements based on the corresponding extension point schema. This includes respecting multiplicity constraints.
Since, the enablement element already has one child, no other legal child elements are allowed to be added (feature is working as expected). Delete the child and the context menu will be populated again with a list of valid child elements from the grammar.
Let me know if this is indeed your problem.
And of cause he is right!
This is indeed a very good new feature. It will help solve a problem I have seen in the applications I have helped develop: the user of an extension point does not really adhere to the contract (the schema) and the extension reader fails...
The only down side: now everybody have to be more careful when defining extension points.
Time from when I reported the bug 'till the bug was marked as INVALID: 73 minutes. I wonder how many commercial systems that has that type of responding support.