Community
Participate
Working Groups
In Jubula and Eclipse for Testers, use of a CompoundContributionItem in a context menu results in duplicate menu items within the context menu. This is confusing at the least, and, with enough repetitions, forces a restart in order to be able to continue working effectively. To reproduce: 0. The Specification Perspective is active and a Project is open. Since the "unbound_modules_concrete" Project is automatically imported with each newly created Jubula database, I would suggest using that Project. 1. Right-click on the "unbound_modules_concrete" Project node in the Test Suite Browser. This opens the context menu, where the bottom entry is a cascading entry labeled "Analyze". 2. Hover over the "Analyze" entry in order to open the cascading menu. The menu has the correct number of entries (2) with no duplicates. 3. Press the Escape key to fully close the context menu (depending on your operating system, you may need to press Escape multiple times in order to fully close the context menu). 4. Repeat steps 1 and 2. The cascading menu now contains the wrong number of entries (4), as all of the original entries are duplicated. 5. Repeating steps 1 and 2 again results in 6 cascaded menu entries. The "original" entries seem to be re-added each time the menu is opened. The declaration for the contribution is at: http://git.eclipse.org/c/jubula/org.eclipse.jubula.core.git/tree/org.eclipse.jubula.client.analyze.ui/plugin.xml#n25 and the implementation is at: http://git.eclipse.org/c/jubula/org.eclipse.jubula.core.git/tree/org.eclipse.jubula.client.analyze.ui/src/org/eclipse/jubula/client/analyze/ui/contributionitems/ContextMenuContributionItem.java I am, as always, open to workarounds or being told that I'm doing it wrong (provided I'm told in the same comment how to do it right :]).
(In reply to comment #0) > In Jubula and Eclipse for Testers, use of a CompoundContributionItem in a > context menu results in duplicate menu items within the context menu. This is > confusing at the least, and, with enough repetitions, forces a restart in order Zeb, is there some magic to get this working in Eclipse? I installed the latest Jubula from https://hudson.eclipse.org/hudson/job/jubula-juno/lastSuccessfulBuild/artifact/jubula/org.eclipse.jubula.site/target/packed/site_assembly.zip - given in bug 367094 comment #21 - and each time I try to do anything I get class not found and persistence exceptions, like: Caused by: java.lang.ClassNotFoundException: org.eclipse.jubula.client.analyze.ui.internal.context.Project and Entity class [class org.eclipse.jubula.client.core.model.SpecObjContPO] has no primary key specified. I tried grabbing the source, and after managing to get it to compile and running a target platform I encounter the same exceptions. Am I missing something?
(In reply to comment #1) > I installed the latest Jubula from ... > Should have also mentioned the same problems occur when I install Jubula from the official Juno update site.
(In reply to comment #2) > (In reply to comment #1) > > > I installed the latest Jubula from ... > > > > Should have also mentioned the same problems occur when I install Jubula from > the official Juno update site. Not sure what was wrong, but after I deleted all of the files located in my .jubula folder and restarted I can at least import the "unbound_modules_concrete" project now.
I'm also not sure what the problem might have been. The .jubula directory is the default location for the configuration area, log files, and H2 database files though, so I guess there was some kind of problem with the configuration area... Are you still encountering issues that block you from analyzing this bug?
(In reply to comment #4) > Are you still encountering issues that block you from analyzing this bug? No, I have successfully reproduced it. The problem is definitely on the platform UI side - CompoundContributionItem#getContributionItemsToFill calls out to dispose any 'old' contribution items but that call does not seem to be removing the menu items from the menu, so we continually add the same two menu entries over and over.
(In reply to comment #5) > The problem is definitely on the platform UI side - > CompoundContributionItem#getContributionItemsToFill calls out to dispose any > 'old' contribution items but that call does not seem to be removing the menu > items from the menu, so we continually add the same two menu entries over and > over. Those items should be deleted in org.eclipse.jface.action.MenuManager.update(boolean, boolean) called from org.eclipse.jface.action.MenuManager.handleAboutToShow() CompoundContributionItem always returns true for isDirty and isDynamic. PW
I created an example project in a topic branch: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/tree/examples/org.eclipse.ui.examples.bug379426?h=pwebster/bug379426 Open the Sample View and right click. http://git.eclipse.org/c/platform/eclipse.platform.ui.git/tree/examples/org.eclipse.ui.examples.bug379426/plugin.xml?h=pwebster/bug379426#n21 is setup the same way as the Jubula contribution, and http://git.eclipse.org/c/platform/eclipse.platform.ui.git/tree/examples/org.eclipse.ui.examples.bug379426/src/org/eclipse/ui/examples/bug379426/views/DynamicItem.java?h=pwebster/bug379426 contributes 2 MenuManagers with commands underneath them. The Sample View creates the context MenuManager with removeAllWhenShown == true. Zeb, is that what your view does? How does "Test Suite Browser" register its context menu, and populate it with items? By hovering over Analyze and then hitting ESC I cannot reproduce with my setup. Mike, can you try my project on Windows (I'm on linux). Zeb, it would be instructive if you could try that sample project in your development environment as well. PW
(In reply to comment #7) > I created an example project in a topic branch: > By hovering over Analyze and then hitting ESC I cannot reproduce with my setup. > Mike, can you try my project on Windows (I'm on linux). > > Zeb, it would be instructive if you could try that sample project in your > development environment as well. Using your project (Paul) as-is I cannot reproduce any duplication. Looking at the Jubula code they actually have a MenuManger that they add two more MenuManagers to to create their Analyze popup menu. Even after changing your example I cannot reproduce = if I set #RemoveAllWhenShown to false I get some funky duplication, but not exactly like what Jubula is experiencing. So next I tried setting the #RemoveAllWhenShown flag on the MenuManagers which had no effect until I added it to the root manager in their abstract view class (AbstractJBTreeView) but that then broke all of their popup menus (no items except the Analyze item showed up) - but did stop the duplication.
(In reply to comment #7) > The Sample View creates the context MenuManager with removeAllWhenShown == > true. Zeb, is that what your view does? How does "Test Suite Browser" > register its context menu, and populate it with items? > ... > Zeb, it would be instructive if you could try that sample project in your > development environment as well. > > PW The context MenuManager is created with removeAllWhenShown == false. The code for context menu registration is at: 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/AbstractJBTreeView.java#n274 Michael's additional assessments are correct: * The "Analyze" menu contribution is realized by returning multiple MenuManagers from the CompoundContributionItem's getContributionItems() method. * Setting removeAllWhenShown == true removes the duplication problem, but also removes all of our other entries. Is it still worth trying the sample project you've created? Or has Michael already provided enough information about how the project behaves in his environment?
(In reply to comment #9) > Is it still worth trying the sample project you've created? Or has Michael > already provided enough information about how the project behaves in his > environment? Is my sample project incorrect then? Should there be one more level of MenuManager returned? Based on the plugin.xml links, I though the Analyse menu was part of the plugin.xml ... is there another level under it? PW
(In reply to comment #10) > Is my sample project incorrect then? Should there be one more level of > MenuManager returned? Based on the plugin.xml links, I though the Analyse menu > was part of the plugin.xml ... is there another level under it? > > PW I think that the menuMgr.setRemoveAllWhenShown(true) call is incorrect, since we are not calling it when creating our MenuManager. As mentioned previously, setting this to true causes our other context menu entries to not be displayed. I've changed it to false in my copy of your example, so the behavior described below is based on that change. Other than that, we also add a GroupMarker for "additions", but that seems to not make a difference in the example. I also don't see a menuAboutToShow listener in Jubula's context menu registration code. The "Analyze" menu is indeed part of the plugin.xml, just like in your example. We also programmatically add one level of cascading followed by leaf entries, just like in the example. However, the effects are strangely different. I'll attach some screenshots to better illustrate this, but it boils down to: * For Jubula, the cascaded context menu entries are duplicated. * For the example, the "Analyze" entry disappears completely, and other (top-level) entries are duplicated.
Created attachment 215953 [details] pwebster Sample: Screenshot after opening context menu for first time
Created attachment 215954 [details] pwebster Sample: Screenshot after opening context menu for second time
Created attachment 215955 [details] pwebster Sample: Stacktrace after opening context menu for second time This stack trace occurs for the sample from pwebster, but not for Jubula. May or may not be relevant.
Created attachment 215956 [details] Jubula: Screenshot after opening context menu for first time
Created attachment 215958 [details] Jubula: Screenshot after opening context menu for second time
(In reply to comment #11) > > I think that the menuMgr.setRemoveAllWhenShown(true) call is incorrect, since > we are not calling it when creating our MenuManager. As mentioned previously, > setting this to true causes our other context menu entries to not be displayed. > I've changed it to false in my copy of your example, so the behavior described > below is based on that change. That's OK. There are 2 ways to do context menus. The most common is to set removeAllWhenShown to true and add a IMenuListener that fills in the basic outline of the menu on every show. That's in my example. But the other way, which is valid, is to leave removeAllWhenShown as false and only add the basic outline of the menu once. It unfortunately doesn't get as much testing as the first way. > I also don't see a menuAboutToShow listener in Jubula's context menu > registration code. Right, you wouldn't use it if you leave removeAllWhenShown as false. Thanx for the update. PW
(In reply to comment #13) > Created attachment 215954 [details] > pwebster Sample: Screenshot after opening context menu for second time This is because or my IMenuListener ... it should be removed if removeAllWhenShown is false. PW
(In reply to comment #10) > (In reply to comment #9) > > Is it still worth trying the sample project you've created? Or has Michael > > already provided enough information about how the project behaves in his > > environment? > > Is my sample project incorrect then? Should there be one more level of > MenuManager returned? Based on the plugin.xml links, I though the Analyse menu > was part of the plugin.xml ... is there another level under it? > > PW No, Your sample is fine, there are two code paths in the Jubula code, one creates two menumangers for the Analyze menu and one create a menumanager containing other menumanagers. > For the example, the "Analyze" entry disappears completely, and other > (top-level) entries are duplicated. even after tweaking Paul's example to remove the listener I still could not duplicate the Jubula behavior.
After a bit of debugging, it looks to me like the problem originates in MenuManagerRenderer: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/tree/bundles/org.eclipse.e4.ui.workbench.renderers.swt/src/org/eclipse/e4/ui/workbench/renderers/swt/MenuManagerRenderer.java?id=1a449bf450b3b2276d9416226c553665bc04dfff#n813 There's an if-statement there that checks whether the contribution item is an instance of MOpaqueMenu. Our declaratively contributed (non-dynamic) contributions are instances of MOpaqueMenuImpl, but the dynamic contribution is an instance of MenuImpl. Unfortunately, I don't have enough PlatformUI / e4 knowledge to know if this is relevant, so I wanted to mention it just in case it is. I'm also adding Markus to the CC list as he'll be the Jubula contact for this bug over the next few weeks.
(In reply to comment #20) > > I'm also adding Markus to the CC list as he'll be the Jubula contact for this > bug over the next few weeks. I've cloned the git repo. Is there a PSF or wiki that describes the plugins I need to import so that I can run the test case from comment #0 in an inner? PW
I'm working from http://wiki.eclipse.org/Jubula/JubulaContribGuid and have the orbit bundles installed based on the org.eclipse.jubula.project.configuration/target/definitions/indigo.target Most projects complain they can't find javax.persistence 2.x ... Orbit only has 1.0.0 PW
javax.persistence 2.x is available from the Indigo p2 repo. It's probably also available from the Juno repo as well.
(In reply to comment #23) > javax.persistence 2.x is available from the Indigo p2 repo. It's probably also > available from the Juno repo as well. I picked up the org.eclipse.persistence.jpa.feature.group, and that seemed good enough. When I launch with the jubula plugins within an Eclipse IDE I get a lot of errors saying some jubula bundles won't start. Should I be launching a more specific application? Caused by: org.eclipse.jubula.tools.exception.GDConfigXmlException: null : null ---- Debugging information ---- cause-exception : java.lang.reflect.UndeclaredThrowableException cause-message : null class : org.eclipse.jubula.tools.xml.businessmodell.CompSystem required-type : org.eclipse.jubula.tools.xml.businessprocess.ConfigVersion path : /compSystem/configVersion/majorCustomVersion line number : 17 ------------------------------- at org.eclipse.jubula.toolkit.common.xml.businessprocess.ComponentBuilder.getCompSystem(ComponentBuilder.java:197) at org.eclipse.jubula.client.core.ClientTest.<init>(ClientTest.java:204)
I created a product based on org.eclipse.jubula.app.product and launched it. I hit that same root cause exception that prevents the app from starting. Caused by: org.eclipse.jubula.tools.exception.GDConfigXmlException at org.eclipse.jubula.toolkit.common.xml.businessprocess.ComponentBuilder.getCompSystem(ComponentBuilder.java:197) at org.eclipse.jubula.client.core.ClientTest.<init>(ClientTest.java:204) at java.lang.J9VMInternals.newInstanceImpl(Native Method) PW
You might need to include the toolkit provider bundles (essentially all *.toolkit.provider.* bundles) if you haven't already. These are not a dependency, but they are generally required in order to be able to do anything meaningful with Jubula. Hope that helps.
(In reply to comment #26) > You might need to include the toolkit provider bundles (essentially all > *.toolkit.provider.* bundles) if you haven't already. These are not a > dependency, but they are generally required in order to be able to do anything > meaningful with Jubula. Thanx, that got me much further. No I get an NPE: java.lang.NullPointerException at org.eclipse.jubula.client.ui.utils.ErrorHandlingUtil$1.run(ErrorHandlingUtil.java:104) at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:180) at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:150) at org.eclipse.swt.widgets.Display.syncExec(Display.java:4291) at org.eclipse.jubula.client.ui.utils.ErrorHandlingUtil.createMessageDialog(ErrorHandlingUtil.java:100) at org.eclipse.jubula.client.ui.utils.ErrorHandlingUtil.createMessageDialog(ErrorHandlingUtil.java:208) at org.eclipse.jubula.app.core.JubulaWorkbenchAdvisor.eventLoopException(JubulaWorkbenchAdvisor.java:269)
(In reply to comment #27) > (In reply to comment #26) > > You might need to include the toolkit provider bundles (essentially all > > *.toolkit.provider.* bundles) if you haven't already. These are not a > > dependency, but they are generally required in order to be able to do anything > > meaningful with Jubula. > > Thanx, that got me much further. No I get an NPE: > That app won't launch for me. Is there some list of bundles that I should include in the IDE so that it should work? I've switched back to that, but even though the IDE launches with the *.toolkit.provider.* it goes back to failing to start org.eclipse.jubula.client.ui.rcp because of throwing the extra exception from ComponentBuilder.getCompSystem(ComponentBuilder.java:197) PW
Created attachment 216130 [details] Jubula launch configuration Here's a launch configuration that works for me. I've tried to sort out the additional (non-Eclipse) stuff, so I apologize if I missed something.
(In reply to comment #29) > Created attachment 216130 [details] > Jubula launch configuration > Thanx Zeb. I can now reproduce the problem in the Test Suite Browser. PW
The reason that my sample doesn't show the problem, but Jubula does, has to do with context menu registration order in org.eclipse.jubula.client.ui.rcp.views.AbstractJBTreeView.registerContextMenu() Moving getSite().registerContextMenu(contextMenu, getTreeViewer()); to the end of the method fixes the problem for me. It was like that in my sample project. PW
Thanks for looking into this, Paul. I've implemented the change you suggested, so hopefully that will run through some tests soon. Provided our tests for bug 378221 pass, this bug is no longer an issue for us. In that case, how do we resolve it (invalid, wontfix, etc.)?
(In reply to comment #32) > Thanks for looking into this, Paul. I've implemented the change you suggested, > so hopefully that will run through some tests soon. Provided our tests for bug > 378221 pass, this bug is no longer an issue for us. In that case, how do we > resolve it (invalid, wontfix, etc.)? I would still leave this open, drop it down to major, and move it into 4.2.1 until I can find the semantic difference between registering before or after creating the SWT Menu. I'm trying to replicate this in my sample project now. PW
The sample project can now replicate the problem http://git.eclipse.org/c/platform/eclipse.platform.ui.git/tree/examples/org.eclipse.ui.examples.bug379426?h=pwebster/bug379426 PW
This bug is related to Bug 365903, in fact, reverting the patch for that bug results in the same behavior also when the order of registration is changed back, see comment 31. In bug 365903 the 'cleanUpContributionCache' call is added to the 'createModelFor' method in the PopupMenuExtender (line 190). The difference between the working and non-working version of the example project is that 'registerE4Support' method is skipped if the menu is not created when the menu-manager is registered. Apparently, 'cleanUpContributionCache' does not work correctly if the menu is not registered with the MenuService.
New Gerrit change created: https://git.eclipse.org/r/136045
New Gerrit change created: https://git.eclipse.org/r/136152
*** Bug 427812 has been marked as a duplicate of this bug. ***
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.
