NSPanel closes when interacting with native context menu

[doroved]

ahkohd/tauri-nspanel#27 (comment)

Hi.
When we open the context menu and click on or off a menu item, NSPanel closes.
Is there any way to fix this? Thanks)

UPD:
After the NSPanel closes, we see the focus go away from the Arc browser and if you call the context menu in the NSPanel after that, it will not close.

2024-04-01.04.57.20.mov

[ahkohd]

Thanks for reporting this. I will get back to you with a fix.

[doroved]

Thanks for reporting this. I will get back to you with a fix.

Thank you so much for your responsiveness)

[ahkohd]

A quick update: I have partially fixed the issue; however, the fix I introduced resulted in another problem.

You can check out this branch to see what I'm up to.

The quickest solution is to use a non-native custom menu.

[ahkohd]

Ayo! I have fixed all the issues, see PR: #40

Please check out this branch and test thoroughly. Let me know if it works!

[doroved]

Ayo! I have fixed all the issues, see PR: #40

Please check out this branch and test thoroughly. Let me know if it works!

Yes, fine, the panel doesn't close.
You may notice that after closing the context menu, the focus leaves the browser. If this can be fixed, it would be perfect.

2024-04-14.22.24.27.mov

[ahkohd]

I'm afraid I haven't found any solution to that.

[ahkohd]

That's a little glitch; the user will probably never notice. Can we mark this issue as resolved by merging the PR?

[doroved]

That's a little glitch; the user will probably never notice. Can we mark this issue as resolved by merging the PR?

Ok, thanks) If you have time, please consider one more issue from me in this repository) I tried to do it myself, but without object-c knowledge it looks like the chance of luck is minimal )

[ahkohd]

One more thing,

A panel with the NSWindowStyleMaskNonactivatingPanel style mask is designed not to take focus from the active application or window when clicked or interacted with. These panels are ideal for transient, ancillary windows like tooltips, floating toolboxes, etc.

Although it is technically possible to use a context menu in a non-activating panel, Cocoa or AppKit do not have any technical restrictions preventing it. However, it might not be the best approach to take. Since the panel doesn't take focus, navigating the context menu with arrow keys could lead to unexpected behavior. In this case, it may cause a glitch where the active window loses focus.

An alternate approach would be to custom-build a non-native context menu or leverage the ones from an existing component UI library.

Take the Krisp as an example, which has managed to implement these scenarios effectively:

[doroved]

@ahkohd
Thanks for the information.
By the way, another point is that the elements inside the panel may behave incorrectly, for example,

• if the panel has a large list, let's say 1000 elements and if you quickly open/hide the panel, this list will disappear and appear after a small scroll.
• scroll position may not be saved
• when opening the panel, the first element (link, button, etc.) is automatically focused.
  The first case is hard to reproduce outside my project, so I couldn't create a repository with an example.

I found a solution to this problem by simply accessing the panel not via
panel.show(), but through window.show() and then the elements inside the panel behave correctly while retaining the advantages of NSPanel.
Example:

fn init(window: Window<Wry>) {
  let panel = window.to_panel().unwrap();
  // ...
  panel.set_delegate(delegate);
  // panel.show();
  window.show().unwrap();
}

fn setup_shortcut(app: &mut tauri::App, accelerator: &str) {
    // let panel = app.get_panel("main").unwrap();
    let window = app.get_window("main").unwrap();

    let mut shortcut = app.global_shortcut_manager();
    shortcut
        .register(accelerator, move || {
            // if panel.is_visible() {
            //     panel.order_out(None);
            // } else {
            //     panel.show();
            // }
            if window.is_visible().unwrap() {
                window.hide().unwrap();
            } else {
                window.show().unwrap();
            }
        })
        .unwrap_or_else(|err| println!("{:?}", err));
}

[doroved]

Take the Krisp as an example, which has managed to implement these scenarios effectively:

This application does not use NSPanel, so there would be no problems with native context menu there.
But yes, in our case we will have to implement the context menu component on the frontend side.