@uuiv I changed your “trust level” from “new” to “member”. You should be able to upload the video now-
@uuiv Actually, I think we do not need the video 
, but here is a test that will help us confirm that bug:
In both browsers, open the DevTools console (F12) and run window.devicePixelRatio.
Prediction: Firefox says 1, Chromium says something else — and the cursor lands at exactly 580 × thatValue, 640 × thatValue.
Also check the Ui.Vision run log for the [desktop scope, × …] line, and run echo $XDG_SESSION_TYPE to confirm X11 vs Wayland.
Workaround: launch Chromium with --force-device-scale-factor=1 (or remove the Xft.dpi / GTK scale override that’s inflating Chromium’s dPR).
→ Your window.devicePixelRatio readings from both browsers will confirm the diagnosis before we build the fix.
Thank you for the answer!
$ echo $XDG_SESSION_TYPE
x11
Both FF and Chromium have window.devicePixelRatio=1
Video uploaded
[status]
tmp.js started
[info]
Executing: uiv.desktop.move {“x”:580,“y”:640,“frameId”:0,“frameLocal”:false,“scope”:“desktop”,“tag”:“”}
[info]
XMove → screen (435, 480) [desktop scope, × 0.75]
[info]
perf: 1 commands, avg 865ms each (tab 163, dispatch 92, wait-start 0, run 610) — first 865ms, slowest XMove 865ms
[info]
tmp.js completed (Runtime 14.15s)
It would be great if the previous views could be preserved, as they make it much easier to create and edit macros, as well as enable or disable individual actions when needed. With JavaScript macros, everything is grouped into a single script, which can make troubleshooting and maintenance more difficult. Even better, if macros could be viewed and edited in all three views, users could choose the format that works best for them. That would be the perfect solution.
@uuiv Thanks for the quick checks - X11 session and devicePixelRatio = 1 in both browsers actually rules out our first theory (a display-scaling mismatch). With those values, both browsers should be sending the native host the exact same coordinates, so now we want to find out where the wrong number appears: on the extension side (aiming) or in the host process (landing).
- Run the click accuracy self-test in both browsers
Ui.Vision ships some diagnostic macros. In the macro tree, open the folder Real User Input and run XClickAccuracyRange.js — once in Chromium, once in Firefox. It fires five real OS clicks at known coordinates and measures where each one lands.
At the end it shows a verdict box on the page (the same text also appears in the log). Please paste the verdict text from both browsers. The verdict already tells the failure pattern apart: a constant offset on every shot, an error that grows with distance (= a scaling factor is wrong, and it names the factor), or shots that never arrive.
(If you don’t see the folder, the demo macros can be restored from the Ui.Vision settings.)
- Paste the aim line from the log
Run your uiv.desktop.move(580,640); macro in Chromium and look in the Ui.Vision log for a line like:
XMove → screen (…, …) [desktop scope…]
Please paste it exactly. This is the coordinate the extension actually sent to the host — if it says (580, 640), the extension aimed correctly and the problem is on the host/environment side; if it shows other numbers or a × N suffix, we’ve found it (that would point at a page-zoom setting on the extension panel — Ctrl+0 with the panel focused resets it).
- Ground truth with xdotool (if installed)
xdotool mousemove 580 640
xdotool getmouselocation
Does that land where you expect? And right after the wrong uiv.desktop.move, run xdotool getmouselocation once more and tell us the numbers — whether the miss is proportional (e.g. everything ×1.2) or a fixed offset points at different code.
- Only if step 1 passes in Chromium: run Desktop Automation →
DesktopClickAccuracyRange.jsin Chromium too and paste its verdict. Its later parts test the screen-pixel path that uiv.desktop.move uses directly.
Thanks for helping debug this!
Thanks for directions! Sorry I’ve too late added Chromium log XMove → screen (435, 480) [desktop scope, × 0.75] in the last post.
This XMove → screen (435, 480) [desktop scope, × 0.75] is the same in UI.Vision Browser mode and in Open IDE Window (even in full screen mode).
Indeed Ctrl+0 reset 0.75 to 1 and the next run become right: [info] XMove → screen (580, 640) [desktop scope]
The problem with XMove (it leads also to clicks in wrong places) is mostly solved, probably in the case when x N not = 1 it is needed to recalculate coordinates.
More bad things are often disappearing of the blue button Play (Ctrl+0 does it as well) and when editing cursor jumping to the top left corner.
Thank you for help and the great project!
getting this error for every single script now
Version 10.0.178 Chrome/Firefox
error]
_adLogin.js failed: Syntax error: unknown: Unexpected token (720:0)
718 |
719 | uiv.log(`LOG: End AD Login`, "blue");
> 720 |
| ^ (line 720) (Runtime 0.55s)