Frontmatter
| id | 5031 |
| title | controller.Application: should not catch contextMenu without explicit debug choice |
| state | Closed |
| labels | bug |
| assignees | tobiu |
| createdAt | Oct 18, 2023, 2:18 PM |
| updatedAt | Mar 8, 2024, 7:36 AM |
| githubUrl | https://github.com/neomjs/neo/issues/5031 |
| author | gplanansky |
| commentsCount | 4 |
| parentIssue | null |
| subIssues | [] |
| subIssuesCompleted | 0 |
| subIssuesTotal | 0 |
| blockedBy | [] |
| blocking | [] |
| closedAt | Mar 8, 2024, 7:36 AM |
controller.Application: should not catch contextMenu without explicit debug choice

Hi George,
obviously, what you can change inside the dev tools (console) also works inside your code :)
Meaning: you could just write Neo.util.Logger.enableComponentLogger = false; into your app / top level view controller.
@Dinkh implemented it in a way, that only CTRL & right clicks will trigger it (which is otherwise not used inside the browser context).
regarding the listener: by default. contextmenu is treated as a global event in neo. meaning: there is just one DOM based listener and it will send this event including the full dom nodes path to the app worker anyway.
so what the logger does is just a subscription inside the app worker realm (manager.DomEvent). of course other components can subscribe to it as well and trigger their own logic.

I see, thanks for explaining. (So why does logger subscribe in Application (and when should we), instead of in Logger itself?)
How about amending the proposal to make enableComponentLogger a DefaultConfig property, to conveniently choose whether to enable it in neo-config?
As Neo will not work without a neo-config file it is equally convenient to replicate an enabling entry, an a disabling entry, in the file. The default more or less documents framework opinion.
I encountered use of contextMenu with Plotly, so it seems legit, if perhaps ill-advised, in some circles.

For others who may search on the Ctrl Right-Click behavior:
putting the Neo.util.Logger.enableComponentLogger = false; statement into the app.mjs file conveniently kills the thing.
Inasmuch as Ctrl Right-Click is used in the browser context ... charts e.g. ... a neo-config.json setting would be appropriate. That would document this secret behavior and disable it by default.
Developers would no longer be ambushed by the behavior. Instead, if the option was in the neo-config.json generated by the npx Neo script, developers would be aware this enabling feature from the get-go.
A related option would allow developers to specify an alternative key combination.

hi george,
let's move enableComponentLogger and enableLogsInProduction into src/DefaultConfig so that we can change it inside neo-config.json files.
@Dinkh
Describe the issue
Currently util.Logger properly and usefully responds to a contextMenu click event by listing the components of a browser element.
Logger has logic to limit its response to a development setting. However mouse event handling is a normal developer task so the result is problematical. Logger provides a console command to turn off the response, but that is frustrated by typical app edit/reload cycles.
I propose controlling matters with a boolean "useLoggerContextMenu" setting in DefaultConfig.mjs, with default value: false, in order to require explicit enablement in neo-config.json. If set to true the developer sees the current behavior.
I propose to test that setting in controller/Application.mjs where the Logger's contextMenu listener is added, in order to prevent that listener from being added.
That involves changing two files:
diff controller/Application.mjs controller/Application.mjs.orig 87d86 < 89a89 > 93,95c93,94 < if ( Neo.config.useLoggerContextMenu ) { < Logger.addContextMenuListener(me.mainView); < }; --- > Logger.addContextMenuListener(me.mainView); >