Change:
private _updateParentChangeListener(): void { // Forward parent events to this listener. Parent will change. <del> this._parentChangeListener.value = this._parent.onDidChangeContext(this._onDidChangeContext.fire, this._onDidChangeContext); </del> <ins> this._parentChangeListener.value = this._parent.onDidChangeContext(e => { const thisContainer = this._parent.getContextValuesContainer(this._myContextId); const thisContextValues = thisContainer.value; if (!allEventKeysInContext(e, thisContextValues)) { this._onDidChangeContext.fire(e); } }); </ins> } public dispose(): void {

Discussion:
Testing on Windows Here's what's happening in the following gif: on another cell (not the one who's ... I'm about to click. on the ... of the output cell. menu shows for a split second then goes away. on the same ... menu now shows properly. !
The mouse click on the should not change the editor focus, like the run button.
I think we have a workaround for this on the cell toolbar, but I didn't think it would be necessary here because none of those actions depend on focus. Also maybe it should respect
Still repros for me. It actually repros each time I click the ... now, instead of only the first time.
Only on Windows it seems...
This is like but it seems that issue can have an impact outside of just focus-related context keys. Basically, a context key (cell type, "cell has outputs", etc) changes in the parent CKS, but is overridden in the scoped CKS. So the effective value in the scoped CKS did not change, but the menu still tries to refresh itself and closes. We have a hacky workaround for the original focus issue for the cell title toolbar But actually this can impact any toolbar. I can copy the workaround for the output toolbar for now. Or we can disable the consolidated output toolbar by default. I still have no clue why it works on Linux but not Windows, since they should be using the same custom toolbar.
In the sync today, the vote was to leave this alone since it isn't totally blocking and wasn't noticed in the past 2 or 3 weeks. I think we should either leave it for next month or disable .
The issue is described in and is really about menus in general. It's really annoying and there are some things I can do to fix it. Any one of these would be fine. Child CKS fires an onDidChange event when a value changes in its parent, even when that key is overridden by the child We could check for this and not fire the event in this case at Would probably reduce a lot of noise/unnecessary updating in the workbench. Would take a little refactoring - the doesn't contain enough info to do this. We can expand the event to contain a full list of types that are only exposed internally, not to consumers.

The Menu fires its onDidChange because some context keys were updated, but it doesn't check whether the actual list of menu items changed Maybe it could diff its list of menu items to avoid this. But the Menu doesn't cache a list of menu items, so that isn't currently possible. Calling setActions on the toolbar with an identical list of actions still causes it to hide We could diff the actions to check that here, but that seems too late for that sort of check After writing all this out, I think the first makes sense, and I could take a crack at a PR, lmk what you think
I like that. Also, I do believe the knows enough, the child CKS service would need to know its keys and ask the event if any of those are affected. Otherwise the CKS should have access to all possible implementations of Careful - context keys for menus control not just inclusion into the menu but also enablement and toggle-states. See how is used
I'm thinking the check has to be, whether all of the keys in the event are contained within the child CKS, not some. The method isn't enough for that but I think you are pointing out that I can just check all the implementations, and for example I can see the full list of keys on .