Checkbox clicks are captured before the click is applied, and click indicators are misplaced #69

Description

When recording a workflow containing a checkbox, Mimik captures the screenshot associated with a click before the click has taken effect.

I reproduced this with a minimal JSFiddle containing a standard native HTML <input type="checkbox">, so the issue does not appear to depend on a particular UI framework.

Steps to reproduce

1. Open the JSFiddle reproduction: https://jsfiddle.net/h09zfav2/
2. Start recording with Mimik.
3. Click the checkbox to check it.
4. Examine the screenshot captured for that click.
5. Click the checkbox again to uncheck it and examine the newly captured screenshot.

Expected behavior

The screenshot associated with the click should show the state after the click has been applied.

For example:

• Clicking an unchecked checkbox -> screenshot should show it checked.
• Clicking a checked checkbox -> screenshot should show it unchecked.

Additionally, the illustrated click location should be on the checkbox, not somewhere off to the side.

Actual behavior

The screenshot is consistently one state behind:

• Clicking an unchecked checkbox -> captured screenshot shows it unchecked.
• Clicking a checked checkbox -> captured screenshot shows it checked.

The checkbox itself behaves normally, but the captured screenshot is out of sync with the recorded action.

The screenshot illustrates the state before the action described by the step rather than the resulting state.

The illustrated click location in the screenshot generated by Mimik is not the checkbox. (see the outputted video and pdf, the video especially is awkward)

Reproduction

JSFiddle: https://jsfiddle.net/h09zfav2/

Environment

• Windows 11
• Firefox 154.0.1 (64-bit)
• Mimik 1.1.1, installed as temporary extension by downloading release on Github

Additional observation

I originally encountered this while recording a workflow in the Discord Developer Portal, which appears to use React Aria based on the attributes used. The behavior there is a little different and more severe in that the interaction itself has issues while recording(causing the input to fail entirely, unless the plugin temporarily falls behind my inputs, for instance by pressing and holding alt to create dozens of events - that's probbably a third bug, now that I think about it) as opposed to just being captured in the wrong state. I haven't investigated that behavior sufficiently to provide a reliable minimal reproduction(and doing so while guaranteeing I haven't unintentionally shared private information is difficult), so I'm reporting the simpler checkbox reproduction here first with the hope both issues are resolved. If not, I intend to file a separate bug report for that issue.

Files

Output by Mimik from the recording.

1. Guide on jsfiddle.net.pdf
2. output video'

Example Citation

The jsfiddle code was taken from https://www.w3schools.com/tags/att_input_type_checkbox.asp, and was copied because the way w3schools embeds demos made the behavior harder to observe.