Community
Participate
Working Groups
After deleting some old Menus & adding some new Menus, the old deleted Menus remain as shadows or ghosts. Selecting one of the old Menus leads to an Exception: InjectionException: Unable to process "DirectContributionItem.contribFactory" The following (simplified) code illustrates this... public static void rebuildMenus(final MMenu root) { final List<MMenuElement> childMenus = root.getChildren(); childMenus.clear(); final MDynamicMenuContribution contrib = MMenuFactory.INSTANCE.createDynamicMenuContribution(); /**/ contrib.setContributionURI("bundleclass://..."); final MMenu newMenu = MMenuFactory.INSTANCE.createMenu(); /**/ newMenu.setLabel ("Label"); /**/ newMenu.setVisible(true); /**/ newMenu.getChildren().add(contrib); childMenus.add(newMenu); } See also Eclipse RCP Forum Posting: https://www.eclipse.org/forums/index.php/t/1079242/
Created attachment 268996 [details] Thread Dump shows mMenuElement.setVisible(false); waiting As almost a year has passed by with absolutely no reaction, here is some more Info. > Firstly: I really don't see why Eclipse RCP has no functioning mechanism to remove Menu Items. Incredible! > As a workround we just make them invisible with mMenuElement.setVisible(false); That is a very bad workaround. Anyway, I noticed in a Thread Dump yesterday that sometimes the Workaround waits... ...and waits, and waits without end. > Please see attached Thread Dump.
(In reply to DaveLaw Missing name from comment #1) > Created attachment 268996 [details] > Thread Dump shows mMenuElement.setVisible(false); waiting > > As almost a year has passed by with absolutely no reaction I guess this is because: 1) wrong product assignment and 2) not clear bug description. I honestly can only guess what is the original issue here (e4 menus can't be hiddedn once added?). Can you please provide a better description (steps to reproduce/observed/expected) and simple example project, where one can see the problem.
Not sure what the right product might be: I've change it to e4/UI. Actually the description is 100% spot on: there is no way of deleting Menus. You add them with something like: MMenu.getChildren().add(MMenuFactory.INSTANCE.createMenu()); (pseudocode: see above for exact code) You might expect removal would be: MMenu.getChildren().clear() ...but it doesn't work. After clear() the Menus are still there but cause an InjectionException. (see attached StackTrace) AS A WORKAROUND... ...we are setting the Menus invisible. But, this consumes resources & as I noticed today, the... MMenu.getChildren().setvisible(false) ...Method is resulting in endless waits. (see previously attached Thread Dump)
Created attachment 269004 [details] InjectionException StackTrace
It looks like the Bug is related to Dynamic Menu Contributions. It is sporadic: sometimes it works. Bug occurs on all of the following: a) DynamicMenuContributionImpl.setVisible(false); b) EcoreUtil.remove(DynamicMenuContributionImpl); c) MElementContainer<MMenuElement>.getChildren().remove(DynamicMenuContributionImpl); a), b) & c) all result in an indefinite wait, which is my definition of "blocker", so setting importance to "blocker". Hope this Bug does not get ignored for another year.
Supplement: its NOT confined to Dynamic Menus. Happens with all Menus.
Still happening with Neon.
Can you please provide a sample project where we can reproduce this problem?
I'm afraid I can't, its a very large and complex Project with many subprojects. -> I think the first course of action would be to check the Stacktrace & figure out what's going on... -> but I would also like an answer to the question: "what is the correct way to delete menus" (childMenus.clear(); has no effect)
private void clearMenuItems(final List<MMenuElement> menuElements) { for (MMenuElement menuElement : menuElements) { // For some reason removing the element from it's parent doesn't // hide the element, so make it invisible // Important - change the visibility before removing from the toolbar menuElement.setToBeRendered(false); menuElement.setVisible(false); } menuElements.clear(); } Try this work around
New Gerrit change created: https://git.eclipse.org/r/121227
Kalyan, Can you please provide a test-case or test-project to verify the fix?
Created attachment 273728 [details] PopupMenu addDelete test Import the attached project, Run it as a Product. Selecting the Main menu item "Add Menu" adds a menu item "Label" to the popup menu. Selecting the popup menu item "Delete Menu" deletes the added "Label" menu item from the popup menu.
Verified that the patch fixes the problem in the test project. Please see gerrit for comments.
Gerrit change https://git.eclipse.org/r/121227 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=951b5ae0f9aa34876c15974e7b71b66c57bd6abe
This introduces a blocker regression for EGit: History menu loses almost every entries, so that operating the Git history is not possible anymore (switch head to commit, create branch etc), and for me this meant I have to switch to the older SDK build to be able to bisect the problem with this commit. I see the change is not obvious, so I would propose to revert commit 951b5ae0f9aa34876c15974e7b71b66c57bd6abe immediately because every Git user will be unable to work with the current SDK state.
New Gerrit change created: https://git.eclipse.org/r/122225
Gerrit change https://git.eclipse.org/r/122225 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=aef50bb1d2575c20437801dc019cd1446b1a705b
(In reply to Andrey Loskutov from comment #16) > This introduces a blocker regression for EGit: History menu loses almost > every entries, so that operating the Git history is not possible anymore > (switch head to commit, create branch etc), and for me this meant I have to > switch to the older SDK build to be able to bisect the problem with this > commit. > > I see the change is not obvious, so I would propose to revert commit > 951b5ae0f9aa34876c15974e7b71b66c57bd6abe immediately because every Git user > will be unable to work with the current SDK state. Backing out this change is not the solution. Removing Menus is basic & necessary logic. If EGit has a problem with this, then EGit needs to be corrected. Please open a corresponding change to EGit. What does "I see the change is not obvious" mean?
(In reply to DaveLaw Missing name from comment #19) > (In reply to Andrey Loskutov from comment #16) > > This introduces a blocker regression for EGit: History menu loses almost > > every entries, so that operating the Git history is not possible anymore > > (switch head to commit, create branch etc), and for me this meant I have to > > switch to the older SDK build to be able to bisect the problem with this > > commit. > > > > I see the change is not obvious, so I would propose to revert commit > > 951b5ae0f9aa34876c15974e7b71b66c57bd6abe immediately because every Git user > > will be unable to work with the current SDK state. > > Backing out this change is not the solution. Breaking running software neither. This week we have 4.8 M7 build and keeping the patch in the code would mean, that 4.8 M7 will be unusable for all Git users. > Removing Menus is basic & necessary logic. Sure. But: looks like the bug is pretty old, so we somehow survived without the fix. > If EGit has a problem with this, then EGit needs to be corrected. > Please open a corresponding change to EGit. I'm not the one who needs the patch (yet), I'm one who is affected by the regression. Feel free to debug the problem with the patch and either fix the patch or create appropriate bugs to all affected plugins (not sure that EGit is the only affected plugin). > What does "I see the change is not obvious" mean? There was no explanation at all *what* and *how* the patch is supposed to fix, neither here nor on the commit message. "Try this work around" in comment 10 is not enough to understand the patch, so I've failed to get an idea about the proposed change and so it is for me "not obvious". Please try understand, that *all* platform developers and most of users outside are using EGit plugin. Fixing an old issue by introducing breaking EGit regression means to hinder the work of all those people. This is not acceptable. Here are steps to continue with this bug: 1. Debug the problem with EGit menus. 2. Understand, where the problem is - is this the patch, is this EGit, is there another bug in platform uncovered by the patch. 3. Document findings here. 4. Fix the problem (wherever it is). 5. Provide updated patch explaining what id does and why, in the commit message or on this bug. 6. Validate that basic plugins are still working. 7. Merge the patch.
Kalyan, please fix for 4.10 M1.
*** This bug has been marked as a duplicate of bug 461655 ***
Reopening this bug and targeting it for 4.11.
The regression might have been caused by Bug 543827. As a result of that bug, the model is not up-to-date for Opaque menu items. That is, the opaque items are not added to the model. Though not sure which solution will be better, the patch included in this bug or the patch for bug 461655
*** This bug has been marked as a duplicate of bug 374568 ***
