enigo-rs / enigo

Cross platform input simulation in Rust
MIT License
1.09k stars 109 forks source link

key_click causes app crash when using Tauri #153

Open jackeydou opened 1 year ago

jackeydou commented 1 year ago

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):

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.

code screenshot

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 https://github.com/enigo-rs/enigo/pull/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 commented 1 year ago

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 commented 1 year ago

Okay, I created a new PR to fix it. Could you please try with that branch? https://github.com/enigo-rs/enigo/pull/161

mino01x commented 1 year ago

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 commented 1 year ago

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 https://github.com/tauri-apps/tauri/issues/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 commented 1 year ago

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

pentamassiv commented 1 year ago

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 commented 1 year ago

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

pentamassiv commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

pentamassiv commented 1 year ago

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: https://github.com/tauri-apps/tauri/issues/6421#issuecomment-1533365703

gaandurian commented 1 year ago

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 commented 1 year ago

Okay, thank you for trying it out

Fleebee commented 9 months ago

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

qzd1989 commented 2 months ago

same problem here..... I should saw this issue before.... -_-

pentamassiv commented 4 weeks ago

I created a simple Tauri project. It is using Tauri 2.0 and the latest unreleased version of enigo. Please run it and let me know if it crashes. It worked fine for me on a Mac.

You can run run it by executing the command pnpm tauri dev in the project folder. The program does nothing until you press the keys Ctrl+Alt+n. Then it presses keys to copy and then delete the highlighted text.

Please note that it's likely not the best way to use enough with Tauri because the enigo struct gets created each time. The project will also not work on Linux.