-
-
Notifications
You must be signed in to change notification settings - Fork 597
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Buster-Client] Forces use of primary monitor on multi monitor setup #72
Comments
I'm planning to call operating system APIs directly instead of using robotgo, which has no multi-monitor support and lacks some features the client app will need for better input simulation. |
I guess AHK would work aswell |
only on windows |
I am having a similar problem. If I connect another high res monitor and move the browser to the new monitor, buster will still use positions from the old monitor. |
System
Extension
Bug description
When using User Input Simulation on multi monitor the client will get the browser's relative position from the correct monitor, but will place the cursor on the x and y offset of the OS's primary monitor.
IE: I have two monitors hooked up to my system, ML (left) and MR (right (primary)).
Chrome is open om ML and i trigger buster to do its magic. My cursor will move to MR, but will position itself relatively on the same position as where my browser/recaptcha dialog is, but it's on the wrong monitor.
Moving Chrome to MR will resolve this issue, but this forces me either to use a single monitor for Chrome, or drag it to MR whenever i want to let Buster do its thing
Logs
Browser:
Client app:
The text was updated successfully, but these errors were encountered: