Two clicks that reported success and did nothing

This one happened in the middle of ordinary work, not a benchmark. We were pointing yadagent.com's DNS at Cloudflare, a normal task, using Yad the whole way through: log into the registrar, open Cloudflare, add the domain, fill in a form. Cloudflare's dashboard is a heavy, fast-rerendering single-page app, and it broke two separate things in a row.

The first one: a target that wasn't there anymore

Yad's perception takes a snapshot of the page and hands the model a set of numbered references to click, the same mechanism Research Log #1 already covered for a Power BI dropdown. That post named the fix as a known next step, "re-resolve the element fresh instead of trusting a reference taken from an earlier snapshot", but it was only ever applied by hand, that one time. It was never actually built into the product.

So the same failure came back, this time on Cloudflare. A click reference pointed at an element the page had already replaced. The reference lookup returned either nothing, or a detached node still sitting in memory. Clicking a detached node doesn't error, it just calls getBoundingClientRect(), gets an empty rectangle back, and the click lands at coordinate (0, 0), wherever that happens to be. The action reports ok: true. Nothing relevant happens.

This time the fix went into the product itself: when a reference is missing or disconnected, Yad now searches the live page for an element with the same role and visible name the reference used to point to, and clicks that instead. Automatic, not something a person has to notice and step in for.

The second one: a click with nothing to call

Right after fixing the first bug, a second one showed up on the same page: clicking Cloudflare's record-type dropdown (a styled button standing in for a real <select>) failed with a plain JavaScript error, "X.click is not a function". Checking the run log from earlier in the same evening, the identical error had already happened once before, on a completely different site. Not a one-off, a pattern.

The click code assumed the resolved element would always support a native .click() call. Most of the time it does. This time it didn't, likely a timing issue on an element mid-transition. The fix: try the native call first, and if that's not available, fall back to dispatching a synthetic mousedown, mouseup, and click in sequence, the same approach the existing right-click action in the codebase already used for a different reason. Now plain clicks get the same safety net.

What actually proves this

Both fixes shipped into the running browser extension mid-session, then got tested against the exact page that had just failed, not a fresh attempt somewhere else. The record-type dropdown that threw an error a few minutes earlier opened normally the second time, real options appeared, the record got created. Thirteen new automated tests cover both failure paths directly, since this package had no test coverage at all before tonight.

Neither of these fixes changes any accuracy number we've published. They fix a specific, common failure mode on modern web apps that re-render themselves constantly, the same category of site the benchmark in Research Log #2 didn't happen to touch. What changed is that a category of "click reported success but nothing happened" failures on that kind of site should now recover on their own instead of needing a person to spot it and step in.