Upon clicking a menu item, the MenuEvent receiver only gets the event upon subsequent mouse move (in Win-11)

[yakrider]

Minimal illustrative code is below. Using tray-icon 0.19.2
As mentioned in title, upon clicking the menu item, the MenuEvent receiver only gets the event upon subsequent mouse move .. i.e in the test case, the printout is delayed until a mouse move etc

let test = MenuItem::new ("Test", true, None);
let tray_menu = Menu::new();
tray_menu .append_items ( &[&test] );
let tray_icon = TrayIconBuilder::new() .with_menu (Box::new(tray_menu)) .with_icon (get_icon()) .build() .unwrap();

let menu_channel = MenuEvent::receiver();
let event_loop = EventLoopBuilder::new().build();

event_loop .run ( move |event, _, control_flow| {
    *control_flow = ControlFlow::WaitUntil (Instant::now().add (Duration::from_millis(20)));
    if let Ok(event) = menu_channel.try_recv() {
        println!("menu_channel: {event:?}");
    }
})

Of note, this doesnt happen if using MenuEvent::set_event_handler .. that responds immediately upon menu item click.

However, that has its own issues .. in particular, it wants the closure to be Send, which means we cant send MenuItem (which uses Rc internally), and therefore, there seems to be no way to update the menu-text from the handler.
This seems to not apply to doing so inside the run-loop as runloop only requires FnMut, without needing it to be Send

[amrbashir]

This is probably because of the event loop control flow and not related to this crate. You can try changing the control flow to Poll or a different control flow mechanism and see if it works for you.

[yakrider]

@amrbashir .. no it is not a control flow issue .. I put the WaitUntil in that example specifically so folks would be less inclined to jsut say that. The issue remains the same even with Poll.

Basically, actual menu clicks dont seem to be events that the event-loop ever sees .. they go straight to the menu handler, and polling the menu handler in the event-loop means it will always be the case in such a setup that a menu event only gets to the handler after an event-loop event fires .. which typically means that menu clicks you do only take effect after you move the mouse next!

The solution of course, (which I figured out later by going through what exactly tauri is doing underneath), is to use a proxy .. which tauri itself does.

However, all the examples in this repo, show a control flow like the sample above .. which means every example you have for this project has that same problem in it.

At the very least, you should update all your examples to use an event proxy .. or to specifically note there that all your examples have this bug because of not using an event-proxy.

It is a little funny to have every example in your own repo have the bug described here, and yet immediately close the issue when reported saying that it not an issue related to this crate!

[amrbashir]

The issue is that the event loop is not woken up fast enough to see the tray or menu events as they happen, instead once the mouse moves, the event loop will be woken and you can receive the events.

It is weird that Poll wasn't enough but nonetheless I will update the examples and documentation to use the proxy.

[yakrider]

thanks!

if it helps, when I was debugging the issue, it looked like when the menu actually is opened up, no event-loop poll actually happens (printouts in event loop stopped) .. and the same with WaitUntil .. the 20ms specified there shouldve been like a poll with a 20ms sleep, but again, while the menu is opened, no printout was produced until the menu was closed again.

(In fact, think it was worse than that .. if e.g. the user opened the tray-menu then clicked somewhere outside so the whole tray went away, it looked like the stuck/waiting state of event-loop continued (incl for polls) even after the menu was gone until some other event woke it back up again)