fix drag mouse

[rgarcia]

Did some testing on this site: https://master--5fc05e08a4a65d0021ae0bf2.chromatic.com/?path=/story/core-draggable-hooks-usedraggable--basic-setup

discovered that the number of steps and the delay between them as you drag the mouse is important to finesse

found success with the defaults in this PR, but making them configurable in case users want to deviate

Checklist

• A link to a related issue in our repository
• A description of the changes proposed in the pull request.
• @mentions of the person or team responsible for reviewing proposed changes.

---

Note

Implements smooth drag using relative step movements with configurable per-segment step count and per-step delay, updates OpenAPI, and adds tests.

• Backend (server/cmd/api/api/computer.go):
  • DragMouse: Move along path via mousemove_relative steps with small sleeps for smoothing; derive steps using generateRelativeSteps; support steps_per_segment (default 10) and step_delay_ms (default 50).
  • Add generateRelativeSteps(dx, dy, steps) helper to distribute integer relative moves.
• Tests (server/cmd/api/api/computer_test.go):
  • Add unit tests covering zero, axis-aligned, and diagonal/sloped cases for generateRelativeSteps.
• API/Schema:
  • DragMouseRequest: add steps_per_segment and step_delay_ms (with defaults/min constraints) in server/openapi.yaml and generated server/lib/oapi/oapi.go.
  • PressKeyRequest.keys doc: note items may be combos like Ctrl+t.

^{Written by Cursor Bugbot for commit 9c427f3. This will update automatically on new commits. Configure here.}

[mesa-dot-dev]

Mesa Description

Did some testing on this site: https://master--5fc05e08a4a65d0021ae0bf2.chromatic.com/?path=/story/core-draggable-hooks-usedraggable--basic-setup

This PR improves mouse dragging reliability by introducing configurable steps and delays. Testing revealed that breaking a single drag action into multiple smaller movements with a slight delay is crucial for success.

• New Configuration: Adds the ability to configure the number of steps and the delay for mouse drag operations.
• Sensible Defaults: Provides default values that worked well during testing.
• Flexibility: Allows users to override the defaults if they need to fine-tune the dragging behavior for specific scenarios.

Checklist

• A link to a related issue in our repository
• A description of the changes proposed in the pull request.
• @mentions of the person or team responsible for reviewing proposed changes.

^{Description generated by Mesa. Update settings}

[mesa-dot-dev]

Performed full review of 4ef116e...9c427f3

Analysis

While the PR introduces smooth, interpolated dragging with a mathematically sound approach, potential architectural issues include:

1. The reliance on relative mouse movements may introduce compatibility issues with systems expecting absolute positioning.

2. The added configuration parameters (steps_per_segment and step_delay_ms) could increase API complexity and create maintenance challenges if default values need future adjustments.

3. Precomputing total steps optimizes performance but may increase memory usage for complex drag operations with many segments.

4. The interpolation algorithm, while mathematically precise, might introduce subtle behavioral differences that could affect existing client code dependent on the previous implementation.

Tip

⚡ Quick Actions

This review was generated by Mesa.

Actions:

• Configure your agents

Slash Commands:

• /review - Request a full code review
• /review latest - Review only changes since the last review
• /describe - Generate PR description. This will update the PR body or issue comment depending on your configuration
• /help - Get help with Mesa commands and configuration options

^{4 files reviewed | 0 comments | Review on Mesa | Edit Reviewer Settings}

[hiroTamada]

Just curious

Should the num steps dynamically change by the distance of each segment?

For example, I kinda find (0, 0) -> (1, 1) and (0, 0) -> (1000, 1000) having the same # of steps to be weird.

[rgarcia]

at least in my testing i only saw dragging fail when the delay was too short, so i don't think the number of steps matters as much as the delay between steps