key_click causes app crash when using Tauri

[jackeydou]

Describe the bug
Application will crash when calling key_click function;

To Reproduce

let mut enigo = Enigo::new();
enigo.key_down(Key::Meta);
let key_c = Key::Layout('c');
enigo.key_click(key_c);
enigo.key_up(Key::Meta);

Expected behavior
No crash.

Environment (please complete the following information):

• OS: macOS Ventura 13.0 (22A380), Apple silicon
• Rust: rustc 1.66.0 (69f9c33d7 2022-12-12)
• Library Version: engio master branch

Additional context
I have read this pr #124 and I use the master branch of this crate, but I still have the problem in create_string_for_key fn.

I try to debug it, and when the code executes to the TISGetInputSourceProperty the application will crash.

Exception has occurred.
EXC_BREAKPOINT (code=1, subcode=0x1b346d924)

[pentamassiv]

Hmm, that's not good. In a few days I should be able to borrow a Mac and then I can try it myself. Which keyboard layout are you using? Maybe it has to do with that?

[jackeydou]

Hmm, that's not good. In a few days I should be able to borrow a Mac and then I can try it myself. Which keyboard layout are you using? Maybe it has to do with that?

I tried the Chinese layout and English layout, and both of them have the same problem.

I find a simple demo of the usage of TISCopyCurrentKeyboardInputSource in stackoverflow, and I executed the code below, it runs ok, that's so weird.

#include <Carbon/Carbon.h>
int main() {
    char layout[128];
    memset(layout, '\0', sizeof(layout));
    TISInputSourceRef source = TISCopyCurrentKeyboardInputSource();
    // get input source id - kTISPropertyInputSourceID
    // get layout name - kTISPropertyLocalizedName
    CFStringRef layoutID = TISGetInputSourceProperty(source, kTISPropertyInputSourceID);
    CFStringGetCString(layoutID, layout, sizeof(layout), kCFStringEncodingUTF8);
    printf("%s\n", layout);
    return 0;
}

[pentamassiv]

Thank you for your feedback. One last chance would be that it was a problem with the core_graphics crate and it was already fixed. Could you please try with the changes from #131? If that also fails, I need to look into it on a mac. I hope I will be able to reproduce it so I can investigate it.

[jackeydou]

I clone the repo, override the crate in my project, and upgrade the core-graphics crate, but the problem remains.

[dependencies]
serde_json = "1.0"
serde = { version = "1.0", features = ["derive"] }
tauri = { version = "1.2", features = ["app-all", "clipboard-all", "global-shortcut-all", "http-all", "shell-open"] }
enigo = "0.0.14"

[patch.crates-io]
enigo = { path = "../../../github/enigo" }

[pentamassiv]

Okay, I created a new PR to fix it. Could you please try with that branch?
#161

[mino01x]

I encountered the same problem while using Tauri. I tried running cargo run --example keyboard in the master branch, and it worked. However, upon further investigation, I discovered that the code of the crate I had installed was different from that in the master branch. Therefore, I switched to the last published commit and ran cargo run --example keyboard, but still faced the same issue.

[pentamassiv]

Yes, that is a known problem with Tauri. Unfortunately we currently do not know why this happens. Any insight into it would be very much appreciated. I tried out a bunch of stuff but nothing fixed it. There is an open ticket in the tauri repo tauri-apps/tauri#6421 but so far there has not been any activity on it.
I probably will not have the time to look into Tauri for the next couple of months to investigate this further. Any help on this would be very much appreciated :)

[mino01x]

i published crate enigo-copy@v0.0.14 from the master branch and tested it, it works for me.

[pentamassiv]

I am glad it works for you with the code from master. Were you not able to use:
enigo = { git = "https://github.com/enigo-rs/enigo" }
in your Cargo.toml file or how come you published it on crates.io?

[mino01x]

i didn't expect to there to be such a method, my poor knowledge. thank u

[pentamassiv]

Okay, no problem. It is impossible to delete crates from crates.io, so it is recommended to use a git dependency if you want to try out things like this. Otherwise all names will be used up and authors of libraries will have a problem to find a good name. It is unlikely anybody would want to publish a library under the name enigo-copy, so it's no problem :)

[frasermince]

Hey just wanted to jump in on this. Even after setting my enigo crate to master I am still seeing this issue. Any idea if there's currently a fix for this?

[pentamassiv]

Yes, this is still a known issue even on master. I don't know what the issue is so I can't fix it. There also has not been any activity in the issue opened in the tauri repo. If you want to look into the root cause, I would be very glad to fix it

[ufon]

OK I tested enigo with tauri in only mouse mode and it works well. So the problem is only with the key_click method.

Also, I run directly keyboard example from enigo and it works well too.

Mac OSX Ventura 13.2.1, M1 Max

[alaninnovates]

Any updates here? Or is this just frozen-in-place? I'm still having this on macos ventura (13.1)

[pentamassiv]

I did not have the time to check it out. I wanted to add wayland support and x11 support without xdotools before. There is an issue at the tauri repo where a fix was suggested but nobody seemed to have tried it:
tauri-apps/tauri#6421 (comment)

[gaandurian]

I did not have the time to check it out. I wanted to add wayland support and x11 support without xdotools before. There is an issue at the tauri repo where a fix was suggested but nobody seemed to have tried it: tauri-apps/tauri#6421 (comment)

Tried it, same problem

[pentamassiv]

Okay, thank you for trying it out

[Fleebee]

To anybody still having this issue.
One of my deployment platforms is a macbook on catalina . Intel chip 2013 and randomly started crashing with enigo keypresses. Frustratingly It crashes without any error output.
Specifically :
enigo.key_sequence("String I want to type");

In my tauri main i added startup_tests(); to the beginning which is just a fn that moves the mouse and simulates keypresses.

fn startup_tests() {
    let mut enigo = Enigo::new();
    enigo.mouse_move_to(800, 500);
    enigo.key_down(Key::Control);
    enigo.key_click(Key::Layout('c'));
    enigo.key_up(Key::Control);
}

I also set the enigo version to "0.1.0"

I did this to test if it also crashed on startup, it didnt and suddenly the invoked function from within my app was also no longer crashing the project.

I'm not sure why this worked but it no longer crashes .
I also didnt have this issue on an M1 mac or windows machine