Jason Tsai

Natvie input like `` or `contenteditable` elements still require an undo menu item

Could be related? https://github.com/tauri-apps/tauri/issues/8924

After some tries, I can make it work by setting `ActivationPolicy::Accessory` and `setVisibleOnAllWorkspaces(true)` Can someone else confirm this works? ```rs fn main() { tauri::Builder::default() .setup(| app | { app.set_activation_policy(tauri::ActivationPolicy::Accessory); Ok(())...

Try add `target_os` above the line: ```rust #[cfg(target_os = "macos")] app.set_activation_policy(tauri::ActivationPolicy::Accessory); ``` > I can confirm. Tested using M1 on v2. I didn't use the js bindings, but setting the...

I think that was because `cfg!` marco still compiles the code, it returns a boolean. `#[cfg]` will conditionally compile the code.

I can't reproduce it with the latest 2.0 beta. Does anyone else still have the issue with current beta?

> can someone confirm if this issue happens with https://github.com/tauri-apps/tray-icon? @pewsheen maybe? Yeah, the issue still exists.

It seems the `parent` window is used in the async version only. Maybe we could let non-Linux target use `AsyncMessageDialog` just like it did in `FileDialog`? https://github.com/tauri-apps/tauri/blob/d75c1b829bd96d9e3a672bcc79120597d5ada4a0/core/tauri/src/api/dialog.rs#L70-L75

Hmm... I followed AppFlowy's [tauri-setup](https://appflowy.gitbook.io/docs/essential-documentation/contribute-to-appflowy/software-contributions/tauri-setup), and the `mouseup` does emit after `mousedown` Do you know if this happens in other Tauri app examples?

Thanks for your testing! Just for a record that the event is emitted in the correct order in my macOS 13.4 and 14 devices.