Community
Participate
Working Groups
Now that Navigator view is depricated and maybe removed in a later version we need to move to project exporer (which is not really a plain file explorer like navigator but thats another discussion) But we noticed that in our product we do have the Project Explorer but the context menu doesn't have an "open" or "open with.." menu In my own eclipe i did have those so i started to investigate why that is. With debugging it i did see that the special "open.group" is added. But then i saw that the Menu provider that need to contribute that came from "jdt.ui" (also saying it "overrides: navigator.ui" But JDT are a disabled capability in our product, we need it because DLTK (javascript part) does depend on it. But we don't want it for the rest in the UI or visible to our users. And because of that disabled Java development capability the menu provider that should provide the open stuff is also not doing its thing AND it doesn't fallback anymore to the thing it overrides i could then easily reproduce it by just disable the java development capability in my own eclipse, then i have the same thing, no "open" or "open with.." menu's i don't think disabling a capability should not result in something not showing a tall. But the override of something else should really be fully reverted..
Do you have a direct pointer to the code in JDT that does the overriding? Somewhere in https://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/tree/ ?
i can look it up in the tree but this already gives quite a bit info i think (with action sets and overrides) NavigatorActionService.addCommonActionProviderMenu will get without jdt (so i really remove the jdt plugins from the launch) something like this: CommonActionProviderDescriptor[definedId=org.eclipse.ui.navigator.resources.OpenActions, visibilityId=org.eclipse.ui.navigator.resources.OpenActions, dependsOn=null, overrides=null] then it does show the "open" and "open with" If i add then back jdt (but disabled by capability) then the open actions is this: CommonActionProviderDescriptor[definedId=org.eclipse.jdt.ui.navigator.actions.OpenActions, visibilityId=org.eclipse.jdt.java.ui.javaContent, dependsOn=null, overrides=org.eclipse.ui.navigator.resources.OpenActions] but because of the disabled capability the if: if (!filterActionProvider(providerDescriptorLocal)) { Will be jumped over, so the fillContextMenu will not be done at all. This is done by debugging our product, but i think base eclipse will work exactly the same (with jdt installed) Because i have in my base java eclipse exactly the same behavior.
Indeed it the filtering is applied to late, it probably should be applied in the CommonActionDescriptorManager#findRelevantActionDescriptors or CommonActionDescriptorManager#addProviderIfRelevant. Johan are you interested in providing a patch via Gerrit? The original filtering was implemented by Bug 257598, commit 10c47d1614f553bd7b6f9709a66a90bc76f6f202.
New Gerrit change created: https://git.eclipse.org/r/164703
with the above patch it works yes all the jdt stuff are filtered upfront and the default one is still in there (and is not overwritten by the jdt, it will add itself because the jdt one returns false)
can this patch be applied for 4.18?
(In reply to Johan Compagner from comment #6) > can this patch be applied for 4.18? Johan, how can I test / verify your patch?
thats really easy just install basis java eclipse sdk default workspace create a default project create 1 file in that project ("test.txt") open the project explorer open the context menu of that "test.txt" file now you see "open with.." and "open" context menu's now go to the preferences-> General -> Capabilities disabled the "Java development" under "Development" save that, then open the context menu again of that file.. No "open" or "open with..." anymore.. That should not happen because i just disable the java capability..
I'm not sure I follow: capabilities are by design and definition about hiding UI elements they contribute when they're disabled. The description in comment #0 seems to be about breaking this definition, isn't it?
no it is not, i don't disable those specific ui elements.. i am not wanting to really show and jdt (the disabled stuff) i just want to have the menu items "open" and "open with" in the view that just should be there. So i don't try to display something that is disabled. in short: default eclipse without any jdt plugins on the launch at all, i have open and open width menu items default eclipse with the jdt plugins but as a disabled capability, menu items gone..
so what do we need to change in the gerrit change to fix this? Because this is just a bug, it doesn't make any sense that the menu items are suddenly not there because of a disabled capability which should not result in those menu items not the be there.. (they are not of that disabled capabity)
(In reply to Johan Compagner from comment #11) > so what do we need to change in the gerrit change to fix this? > Because this is just a bug, it doesn't make any sense that the menu items > are suddenly not there because of a disabled capability which should not > result in those menu items not the be there.. (they are not of that disabled > capabity) So JDT defines the capability that includes those menu contribution, but disables it? If so, it seems expected that the menus are hidden, and the issue is not the capability filtering, but more the fact that JDT defines a capability that hides things it doesn't own. It would be a JDT bug.
no they don't define it! they override the default one. And then when that capability is disabled suddenly that menu is disabled. But it shouldn't the thing they overrode should work fine! so we do have by default menu items like "open" and "open with" that gives options even if JDT is not installed at all.. that just works. But when JDT is installed JDT overrides those menu items with its own implementation. and then when JDT is disabled suddenly those menu items are gone... But they should not be gone, there is by default (so none JDT) just menu's for that. those are there those should just be accessible, they are not disabled!
read my comment here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=564176#c2 its really about: CommonActionProviderDescriptor[definedId=org.eclipse.ui.navigator.resources.OpenActions, visibilityId=org.eclipse.ui.navigator.resources.OpenActions, dependsOn=null, overrides=null] vs CommonActionProviderDescriptor[definedId=org.eclipse.jdt.ui.navigator.actions.OpenActions, visibilityId=org.eclipse.jdt.java.ui.javaContent, dependsOn=null, overrides=org.eclipse.ui.navigator.resources.OpenActions] and i think this is coming purely from the plugin.xml of jdt right? they have a provide there own "OpenActions" that overrides the default one. So i really wonder how JDT then can control this if they are suddenly disabled. My patch doesn't do any filtering anymore i still do that: https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/164703/2/bundles/org.eclipse.ui.navigator/src/org/eclipse/ui/internal/navigator/actions/CommonActionDescriptorManager.java#34 it is just moved there. so that we don't add the JDT one (and skip over the default navigator one completely) and then when we show it nothing is being shown because they are all disabled (but the default one wouldn't be) what my patch does is test this upfront.. so go over all the contributions, not add the disabled java one, but add the default one.
"My patch doesn't do any filtering anymore i still do that:" i mean It is not that my patch doesn't do any filtering, it still does that:
OK, so it seems like the CommonActionDescriptorManager.findRelevantActionDescriptors() does not return a provider if it's overridden and override is disabled. If so, I agree with your analysis; looking at the documentation of "overrides" in the extension point schema says "The upstream actionProvider will not be given an opportunity to contribute menu options or retargetable actions when this actionProvider is visible and enabled" and doesn't say that the upstream actionProvider should be altered if overriding one is invisible or disabled. Do you think you could capture the bug in a test case to ensure no further regression can happen?
i can try, do you have a git location of existing test (examples) where this one then should be added to?
(In reply to Johan Compagner from comment #17) > i can try, do you have a git location of existing test (examples) where this > one then should be added to? You can see multiple examples in org.eclipse.ui.tests.navigator bundle. See for example the INavigatorContentServiceTests that checks for extensions; and TestAccessHelper that can be used as example of how to call findRelevantActionDescriptors from a CommonViewer. I see no test that deals with capabilities; you'll need to define some more extensions. That could deserve its own test class.
