[bug] MacOS menu doesn't change based on window

[Sytten]

Describe the bug

This might be a "works as intended" but it should be documented. Basically, the menu stays with the value of the latest call to .menu and doesn't change based on the currently focused window. Meaning that you are kinda forced to use a single menu for the whole application.

Reproduction

1. Start with any basic application
2. Open a second window with with .menu
3. The menu sticks with the menu defined in the second window

Expected behavior

Unsure what behaviour is expected on MacOS, it would be nice if it switched but worst case it should be documented.

Platform and versions

Environment
  › OS: Mac OS 11.6.3 X64
  › Node.js: 16.17.0
  › npm: 8.15.0
  › pnpm: 7.17.1
  › yarn: 1.22.15
  › rustup: 1.25.1
  › rustc: 1.65.0
  › cargo: 1.65.0
  › Rust toolchain: stable-x86_64-apple-darwin

Packages
  › @tauri-apps/cli [NPM]: 1.2.0 (outdated, latest: 1.2.1)
  › @tauri-apps/api [NPM]: 1.2.0
  › tauri [RUST]: git+https://github.com/caido/dependency-tauri?branch=caido#f73dc6487fa9e5ca8f60b092d31ea7f5d8a7a24b (1.2.0),
  › tauri-build [RUST]: git+https://github.com/caido/dependency-tauri?branch=caido#f73dc6487fa9e5ca8f60b092d31ea7f5d8a7a24b (1.2.0),
  › tao [RUST]: 0.15.3,
  › wry [RUST]: 0.22.0,

App
  › build-type: bundle
  › CSP: default-src blob: data: filesystem: ws: wss: http: https: tauri: 'unsafe-eval' 'unsafe-inline' 'self' img-src: 'self'
  › distDir: ../caido-ui/dist
  › devPath: http://localhost:10000/
  › framework: Vue.js

App directory structure
  ├─ dist
  ├─ node_modules
  ├─ scripts
  └─ src

Stack trace

No response

Additional context

No response

[amrbashir]

Since the menu are global on macOS, it is expected that the menu won't change. I think the documentation is clear enough but if it is not, please go ahead and open a PR with a better documentation.

[matthme]

I just came across a similar issue (probably the same root cause):

• Create a main window on startup of the application via tauri::Builder and set a menu via call to .menu on the Builder (https://docs.rs/tauri/latest/tauri/struct.Builder.html#method.menu)
• Create an additional window via WindowBuilder and give it its own menu via call to .menu (https://docs.rs/tauri/latest/tauri/window/struct.WindowBuilder.html#method.menu)
• Upon closing the additional window, the menu remains stuck at its menu and the menu of the main window is lost.

I made a repro here: https://github.com/matthme/menu-stuck-tauri-macos

I don't think this behavior is documented at all and it is quite counterintuitive given that the menu method is part of WindowBuilder.

[FabianLars]

Reopening because it's a really weird situation which needs some clarification (in the docs) or even better a change in behavior.

[FabianLars]

Maybe the menu apis should be on the App|Handle on macos for v2 instead? A bit more annoying to use cross-platform wise but at least it's clear what's happening, and it would prevent that new windows would overwrite the menu without a way to go back.

[amrbashir]

that's indeed the planned changes for v2 leveraging the new menu crate (muda).

[amrbashir]

I think we can internally disable WindowBuilder::menu on macOS so it doesn't cause this behavior for now.

[matthme]

Or would it be possible to have a boolean property overwrite_macOS_main_menu or similar in the menu method?

[Sytten]

Sorry my wording was not very good above, but this is exactly what @matthme said!

[matthme]

Oh, and it comes even worse. It seems that one can't even disable the menu for an external window on Linux (and probably also Windows but not tested): https://github.com/matthme/menu-stuck-tauri-macos/tree/inherit-menu Omitting the menu() method leads to inheriting the menu of the main window. So it's an unresolvable conflict between platforms. I can choose between:

1. One global menu that is forced onto every window
2. Make custom menus for different windows and have the "main" menu be overwritten on macOS

Both are not an option in my case so I have to go with the lesser evil of the two which I think is number 2 for me. Or I'll have to create a JS-based custom menu...

I would at least want to be able to explicitly not show any menu at all on Linux/Windows for external windows.

[matthme]

For people reading this and having a similar conflict between platforms: One may hardly believe it but I had a breakthrough in my Rust skills recently and discovered conditional compilation. So it's easily possible to have different menus on windows other than the main window be only applied to Linux/Windows by simply using platform-specific Rust code. It doesn't solve this issue but at least makes things work on Linux/Windows as intended without negative side effects on the global menu on macOS.