Why Yad got stuck on a dropdown menu
Not a benchmark, not a 92%-success-rate slide. A real failure from this week, exactly as it happened, and the fix that actually worked.
I was using Yad to publish a Power BI report to Power BI Service, live, from a plain-language instruction. Click Import, choose "Report", choose "From this computer", upload the file. Four steps, all inside one dropdown menu on a real production web app, not a demo sandbox we control.
Yad got stuck. Not crashed, not errored, stuck: it clicked the same menu item over and over, fifteen steps in a row, and the menu never actually opened the next screen. Every single click reported back "ok: true". As far as Yad's own action log was concerned, everything was working.
Why "ok: true" was lying
Yad's perception works by taking a snapshot of the page (an accessibility-tree style read of what's clickable) and handing the model a set of numbered references to act on, like e23 or e41. That's fast and it's how most browser agents work. The problem: Power BI's interface is a React app that re-renders itself constantly. Between the moment Yad reads the snapshot and the moment it actually dispatches the click, the underlying DOM node behind that reference can already be gone, replaced by a new one React just created. The click event still fires. It just lands on nothing meaningful, or on a stale element that no longer does what it used to.
That's the actual failure mode: not "Yad can't click things", but "the map Yad is holding goes out of date faster than Yad can act on it," on any interface that re-renders aggressively. A static page never triggers this. A fast, componentized SPA does, constantly.
What fixed it
The fix wasn't a bigger model or a longer prompt. It was changing how the target element gets found in the first place: instead of trusting a reference taken from an earlier snapshot, re-resolve the element fresh, at the moment of the click, by its visible text content. document.querySelectorAll(...) for an element whose text says exactly "Importeren", right before clicking it, not a reference cached thirty milliseconds earlier. That one change took the same four-step Power BI flow from a 0% success rate over three separate attempts to working cleanly, every time, once it was in place.
What this actually means
This isn't a Yad-only problem. Any browser agent that snapshots-then-acts has the exact same exposure on fast-rendering apps, and most of them don't publish what happens when it goes wrong, they publish the runs that worked. I'd rather write down the one that didn't, because "we found the failure mode and here is the fix" is a more honest signal than "92% success rate" with no context for what the other cases looked like.
The concrete next step: build fresh-resolution-by-text as a fallback path inside Yad itself, triggered automatically when a reference-based click reports success but the page state doesn't actually change, instead of needing a person to notice and intervene by hand, which is what happened this time.