-
Notifications
You must be signed in to change notification settings - Fork 28.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
potential listener LEAK detected in menubarControl #161413
Comments
Seeing a similar stack but for custom menus when running browser integration tests:
|
Things are better after #161465 but something still seems to be off. When skipping this if-statement and basically emitting a menu event per context key event the leak warning reappear and they are rooted at the native menu... |
So, this is the problem: there is abstract Whenever a change happens for the global menu ( |
This leak is definitely over-exposed by a previous bug of emitting way too many menu change events but it will also happen without that, just less dramatic. |
…e that map gets cleared repeatedly workaround for #161413
I pushed 4768357 which prevent the leak but there is some debt which can be simplified. I am thinking of the following items
|
@jrieken what is the recommended way to get the submenuitemaction actions since I need the group information that the menu getActions provides. Also, are context keys and such observed? |
That's implicit by the use of
Not sure what you mean by that? |
I guess I'm just confused by the typings. I'm getting a list of IActions. In this context I'm using a lot of information from the menu typings like mnemonic labels and toggled states. I'll continue this in debt week as I don't want to change all the menubar creation on the last day of the iteration. |
Oh, now I get it... Yeah you can safely check for/cast to |
@jrieken after fixing this, there is one minor nuisance that comes out of not manually listening to every submenu onDidChange event. The repro is this: I tested on windows with custom menus:
🐛 it still shows the old name Another context key update eventually gets the entry to update pretty quickly, but since the menu changes but not due to context keys, I don't think they are propagated up. |
Actions (menu items) only react to context keys that they spell out, not to all changes. I am not familiar how the rename profiles command is implemented. Maybe there needs to be another special event for when profiles change? |
Hi, I'm using monaco-editor in React, and when I've upgraded it from 0.33 (released ca. 8 months ago) to 0.34 (released a month ago), I'm constantly getting an error when the editor mounts, and the only place that showed up when i googled Here's the error:
|
settings.json
"editor.renameOnType": true
The text was updated successfully, but these errors were encountered: