Inspector. Close the context menu after click by item{
    explorerExtensibility: [{
        predicate: (node) => === 'ground',
        entries: [{
            label: 'MyAction',
            action: (node) => {},


I think the context menu should close after click :thinking:

cc @carolhmj maybe it should close only if we return true ???

Action has a return void type through, maybe we can add an extra option “closeAfterClick” on the entry to keep backcompat?

Someone needs to save open the context menu after click?
Other context menus in the Inspector work as expected — close after click.

I can see a use case where they would like to do the same action multiple times, so not closing the menu would be useful :thinking: Maybe @PatrickRyan can weigh in here?

Yes, but this reason is actual for any other context menu.
Probably, the idea with return the boolean is good enough to fix this behavior :slight_smile:

@carolhmj, I would agree with @Dok11 here that if we are flying out a submenu, either clicking on an item in the submenu or clicking anywhere else on the screen that is not on the submenu should also close the submenu. We have precedent with other controls in the inspector like all of the select boxes. We also follow that pattern in the playground toolbar items. Opening options will show the submenu, and then once you click on any option in that submenu it will close. Same with clicking on another part of the UI which will close the options submenu.

I think for the most part, users understand from common UX patterns that if you fly out a submenu from a button click, that submenu will close once you click on any options from the submenu or if you click on an area outside the submenu. Obviously we need to keep back compat, but if there’s a solution here that retains back compat and closes the submenu when selecting an option from it, that would be ideal.


That sure makes sense to me.
@Dok11 May be you could open a ‘general topic’ feature request for all changes to the Inspector?
I guess it would be easier to track and get an overall overview; what is your say?

I think it would be hard to discuss different parts of founded bugs or feature requests in a one thread. Even on this topic I still dont know — is it a bug, or a feature request :smiley:

No, it’s a missing part and a feature request. Already agreed by @PatrickRyan the way I understand it. It just needs to be checked for backwards compatibility and if so, it will likely be implemented for v7 (as long as we keep track and eye on it :face_with_monocle: :wink: :grin:
Means you can now move on with your next challenge :smiley:

We could also link them all to a general topic and discuss them separately. :thinking: @carolhmj is the GUI-angel :innocent: from the Team. I don’t know who’s the angel of the Inspector? :thinking: Anyways, I guess we should just wait for the ‘enlightment’ :rainbow: on how we should best handle this? :grin:

It’s ok to keep this as a separate request :slight_smile: Based on the discussion, and as to not break back compat, I think the best solution here will be to add an extra parameter to the extensibility object, so the user can choose if it closes after click or not. It can close the submenu by default as that would be the expected behavior.

1 Like