Community
Participate
Working Groups
Programmatically created CommandContributionItems do not reflect the enablement state of the corresponding command. As already mentioned at bug 366920 comment 4 we, the Jubula team, are currently blocked by the wrong enablement state of programmatically created CommandContributionItem which we use for our view and editor context menus.
This works for most of our CCI contributions, but not for yours. I'm investigating. PW
OK, this might be related to the command/handler isEnabled() support. PW
This is fixed in the latest 4.2 I build, I20111216-1500, as part of the fixes for bug 366560. The problem was Command#isEnabled() was always returning true and that was effecting the state of the CommandContributionItem in popup menus. I tested it in the Sample view with context menu entries: CommandContributionItemParameter copyParm = new CommandContributionItemParameter(getSite(), "copy", IWorkbenchCommandConstants.EDIT_COPY, CommandContributionItem.STYLE_PUSH); manager.add(new CommandContributionItem(copyParm)); and a copy handler that was enabled based on: selection obj; obj instanceof TreeObject && !(obj instanceof TreeParent) PW
In I20120123-2200 PW
This issue does not seem to be completely fixed: closing bug 366920 confirmed that the initial UI enablement state for programmatically created CommandContributionItems is now correct when initially opening the menu, but bug 372987 reports that this enablement state does not continuously and correctly reflects the enablement state of the command over time. Could it be possible that the enablement state does not get updated / reevaluated, e.g. if the selection in a part changes?
The handler is what determines the enabled state. When the state is incorrect, how is the handler determining its state? I'm also not sure about bug 372987 comment #3 You mention delete is incorrect, but it is enabled in both the before and after image? Is it supposed to be disabled in the before but not in the after? PW
Thank you for the quick reply - I hope the inline comments will clarify the problem: (In reply to comment #6) > The handler is what determines the enabled state. When the state is incorrect, > how is the handler determining its state? I assume that the state of the handler is "disabled / not active". E.g. clicking on the wrongly enabled entry of the mentioned "delete"-command menu does not execute the corresponding handler. > I'm also not sure about bug 372987 comment #3 > > You mention delete is incorrect, but it is enabled in both the before and after > image? Is it supposed to be disabled in the before but not in the after? Not exactly - the delete command is supposed to be disabled for this kind of tree node (non-editable == non-deletable child node). I assume that our tester initially selected a deletable node (which caused the command to have an active handler [==enable it's UI state]) and after that a non-deletable node (which is then shown in the screenshot). I am also able to manually reproduce this behavior, first selecting a node for which a certain command has an active handler (context menu gets correctly enabled) - after that selecting another node for which the command has no active handler (context menu stays enabled) and vice versa. > PW
(In reply to comment #7) > > I assume that the state of the handler is "disabled / not active". E.g. > clicking on the wrongly enabled entry of the mentioned "delete"-command menu > does not execute the corresponding handler. That's the code I'm interested in. You are clicking on a node and depending on if it is read-only or not you expect the handler to enabled/disabled. Where does the handler determine its active state? PW
One of the most basic <activeWhen>...-statements can be found here http://git.eclipse.org/c/jubula/org.eclipse.jubula.core.git/tree/org.eclipse.jubula.client.ui.rcp/plugin.xml#n1739 It shows the enablement / activeWhen for a "rename"-handler (which should also be disabled in the context menu for a non-editable tree node). The enablement logic is this: renaming should only be possible for a single selected element which is either an editable category or an editable (so called) SpecTestCase. Though there are multiple handlers for this command "org.eclipse.ui.edit.rename" non of them enables via <instanceof ...> for a (in the UI selected) ExecTestCase node.
I tried running Jubula on 3.8M5 to compare the behaviour but got this error. What did I do wrong, Markus? Caused by: org.osgi.framework.BundleException: Exception in org.eclipse.jubula.client.core.Activator.start() of bundle org.eclipse.jubula.client.core. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:734) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:300) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:440) at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:263) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:107) ... 47 more Caused by: java.lang.ClassCastException: org.slf4j.helpers.NOPLoggerFactory cannot be cast to ch.qos.logback.classic.LoggerContext at org.eclipse.jubula.client.core.Activator.start(Activator.java:53) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702) ... 53 more
We currently experience major inter-project issues which prevents Jubula from working. The one you experience is bug 370807. As a manual workaround for that please see bug 370807 comment #1. You may also modify your environment as mentioned in bug 371350 - EclipseLink also currently contains a blocking issue for Jubula. The easiest way to reproduce this issue is to - download the Juno M5 version of "Eclipse for Testers" : http://build.eclipse.org/technology/epp/epp_build/juno/download/20120202-1517/ - unpack the package and manually remove the bundles - javax.persistence_2.1.0.v201201251030.jar - org.slf4j.api_1.6.4.v20111214-2030 - start eclipse - open "Test --> Open..." - wait for auto db-connection and project import; after that open the preselected project "unbound_modules_concrete" - verify the behavior in the "Test Case Browser" when opening the context menu for: "Test Cases: --> Actions (basic) --> Activate Application --> ub_app_activate_AUTDefault" this node should be rename-able, but non of his children.
I've reproduced the problem with Jubula and have also reproduced the issue with a smaller plug-in project. Unfortunately, I haven't yet figured out the cause yet. Moving to M6 since M5 has shipped.
First problem is that we don't track the variable access of the selection. This explains why the handler proxy never got an enablement change. Even when it gets this change, no events are fired because the handler proxy itself has no listeners attached to it.
Created attachment 212132 [details] Patch I've made changes to the EvaluationService so that accesses to the default variable are actually tracked and to the HandlerProxy so that handler change events will be propagated to the MHG that is connected to the command. This will allow the command to receive notifications should the HandlerProxy change.
Created attachment 212137 [details] Patch v02 Changed to wrap the logic in E4HandlerProxy.
(In reply to comment #15) > Created attachment 212137 [details] > Patch v02 Patch pushed to master. http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=844bbce93cf313a819b87c3ed48d1b5ff4a47e21 Thanks for the bug reports, Markus!
The 'Rename' menu item is now enabled/disabled correctly with the latest I20120307-2200 build.
In I20120313-0610 PW
Unfortunately I am only able to partially agree - though (framework defined) commands like 'Rename' or 'Delete' do now seem to (in Juno M6 Eclipse for Testers) enable / disable correctly, there are still some (the only difference I am sure of is that they are not pre-defined) commands which does not correctly enable / disable e.g. in the our "Test Suite Browser"-view the command 'show specification'. The activeWhen-status of one of the handler can be found here: http://git.eclipse.org/c/jubula/org.eclipse.jubula.core.git/tree/org.eclipse.jubula.client.ui.rcp/plugin.xml#n2920 It's based on various states (variable, selection count, selection type) which are all "ANDed" and at least the instanceof should be *false* for "Test Suites" being selected in our "Test Suite Browser". This commands menu enablement state gets as well falsely enabled as well as disabled. There are also some other commands which are affected by this. In a 3.x environment these commands do not show any problems.
Michael, could you have a look at this? Markus, where's a good site to get the version of Jubula you're working with? We'll need to install it into our latest 4.2 I build as there have been a lot of code changes since M6. PW
I used the EPP version of Jubula "Eclipse for Testers" - available from http://www.eclipse.org/downloads/index-developer.php If you're looking for the most recent installable Jubula feature you could just use the last successful build artifact from our jubula-juno hudson job: https://hudson.eclipse.org/hudson/job/jubula-juno/lastSuccessfulBuild/artifact/jubula/org.eclipse.jubula.site/target/packed/site_assembly.zip The one which is currently included in M6 can be found here: http://download.eclipse.org/jubula/milestones/juno-m6
(In reply to comment #20) > Michael, could you have a look at this? > Sure, I have just installed Jubula, now I just have to figure out how to use it :)
(In reply to comment #22) > (In reply to comment #20) > > Michael, could you have a look at this? > > > > Sure, I have just installed Jubula, now I just have to figure out how to use it > :) Markus, I managed to get Jubula installed, but once installed I could not do anything with it. Is there a simple tutorial, etc that you could point me to so that I can test?
I am not sure how and what you've currently installed from Jubula - but you could try to perform the "First steps"-cheatsheet or the steps from comment 11: verify the behavior in the "Test Case Browser" when opening the context menu for: "Test Cases: --> Actions (basic) --> Activate Application --> ub_app_activate_AUTDefault" this node should *not* show the entry "Show specification" as enabled, but all of his children. Based on which element gets selected first either the enablement or disablement for the node itself or it's children is wrong.
(In reply to comment #24) > I am not sure how and what you've currently installed from Jubula - I installed everything that was available from: https://hudson.eclipse.org/hudson/job/jubula-juno/lastSuccessfulBuild/artifact/jubula/org.eclipse.jubula.site/target/packed/site_assembly.zip > could try to perform the "First steps"-cheatsheet or the steps from comment 11: > verify the behavior in the "Test Case Browser" when opening the context menu > for: "Test Cases: --> Actions (basic) --> Activate Application --> > ub_app_activate_AUTDefault" The problem was that I had to open the "Functional Test Execution" perspective to have the 'Test' main menu item show up. Once opened and selecting a variety of elements the 'Open Specification' command appeared to correctly enable / disable. Markus can you confirm? Note I was testing using: Version: 4.2.0 Build id: N20120417-2000
I am not sure which actual components (Version: 4.2.0 Build id: N20120417-2000) and installation path you used to confirm this. Could you please provide more information how to setup the configuration (eclipse version) you used to verify this?
(In reply to comment #26) > I am not sure which actual components (Version: 4.2.0 Build id: N20120417-2000) > and installation path you used to confirm this. Could you please provide more > information how to setup the configuration (eclipse version) you used to verify > this? To confirm, you would use one of our warm-up I builds, like http://download.eclipse.org/eclipse/downloads/drops4/I20120426-0800/ + the Jubula link mentioned in comment #25 PW
Created attachment 214984 [details] Testsuite Browser Open and Show Specification
Markus asked me to repeat the test for this bug with following installation: - Eclipse SDK 4.2.0.I20120426-0800 - Jubula 1.2.1.201204271118 - Jubula Database Drivers 1.0.0.201106151822 Unfortunately the wrong enablement of context menu items still persists, e.g. for Testsuite Browser context menu(s.attachments of Test Suite Browser context menu). Following items have a wrong state: - Open Specification - Show Specification - Open with Testsuite Editor - Open with Objectmapping Editor Furthermore I miss the keyboard shortcuts in Open Specification and Show Specificaton item. The enablement of delete item in Test Suite Browser seems to be alright now. I plan to test further scenarios next days.
Created attachment 214985 [details] Testsuite Browser Open with context menu
Is there any new version of Eclipse SDK integration build I could test?
(In reply to comment #31) > Is there any new version of Eclipse SDK integration build I could test? Our integration builds are here: http://download.eclipse.org/eclipse/downloads/ The latest build which is our M7 candidate is http://download.eclipse.org/eclipse/downloads/drops4/I20120502-1800/ PW
Multiple problems with wrong enablement state also occurs with M7 candidate Eclipse SDK 4.2.0.I20120502-1800. I will create single tickets for each topic.
(In reply to comment #33) > > I will create single tickets for each topic. That's not necessary unless we determine they are caused by different problems. In the last context menu snpatshot you attached, 3 of the menu items were disabled. Are they created by this code: http://git.eclipse.org/c/jubula/org.eclipse.jubula.core.git/tree/org.eclipse.jubula.client.ui.rcp/src/org/eclipse/jubula/client/ui/rcp/views/TestSuiteBrowser.java#n157 PW
> In the last context menu snpatshot you attached, 3 of the menu items were > disabled. Are they created by this code: > http://git.eclipse.org/c/jubula/org.eclipse.jubula.core.git/tree/org.eclipse.jubula.client.ui.rcp/src/org/eclipse/jubula/client/ui/rcp/views/TestSuiteBrowser.java#n157 > > PW Yes, all 4 context menu contributions (also the enabled one) are created with the referenced code.
bug 378467 (applied to Test Suite Browser) seems to be a simple way to reproduce the error. Essentially: 0. Functional Test Specification Perspective is active, and a Project with Test Suites containing references to Test Cases is open. 1. Open a Test Suite in the Test Suite Editor. 2. Open context menu on a Test Suite in the Test Suite Browser. Menu item enablement is correct. Do *not* close context menu. 3. (Left) click on Test Suite in Test Suite Editor. The "Add Test Case Reference" dialog appears. This should not occur, but this error is captured in bug 378467. 4. Cancel the dialog. 5. Open context menu on a Test Suite in the Test Suite Browser. Several items that should be enabled are instead disabled. The enablement state can be corrected by closing the Test Suite Browser and then opening it again.
Moving to RC1...
(In reply to comment #34) > In the last context menu snpatshot you attached, 3 of the menu items were > disabled. Are they created by this code: > http://git.eclipse.org/c/jubula/org.eclipse.jubula.core.git/tree/org.eclipse.jubula.client.ui.rcp/src/org/eclipse/jubula/client/ui/rcp/views/TestSuiteBrowser.java#n157 This code has changed (because of a fix in Jubula). I can't reproduce this problem with my example CommandContributionItem (it's enabled/disabled by my handler). Is it no longer an issue? PW
(In reply to comment #38) > This code has changed (because of a fix in Jubula). I can't reproduce this > problem with my example CommandContributionItem (it's enabled/disabled by my > handler). Is it no longer an issue? > > PW We've been converting Jubula's context menus from programmatic to declarative as a mitigation strategy in case this bug is not resolved in time for Juno. I've performed this conversion for the Test Suite Browser, Test Case Browser, and Object Mapping Editor (the places where the error was reliably reproducible). Those changes are documented on bug 372987. As we seem to have found a functioning workaround, I'd say this is no longer an issue for Jubula. I don't know whether other projects are having similar difficulties and just haven't noticed yet (as it can be tricky to reproduce).
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. -- The automated Eclipse Genie.
