pup_evaluate is misrouted to pup_hover - every call returns hover_target_missing - Pup - the AI's own browser

by adom

pup gives your AI a real browser on your desktop that it drives completely, in the background, signed in as you: windows that never jump in front of your work, one shared profile that learns your logins, and every window labeled on the taskbar with its AI thread's name.

Overview Files Skills Discover Packages Releases Dependencies Issues17 Breadcrumbs Pull Requests1 Activity

Closed general

pup_evaluate is misrouted to pup_hover - every call returns hover_target_missing

John Lauer · 2mo ago ·closed by John Lauer

`pup_evaluate` is misrouted to `pup_hover` — every call fails with `hover_target_missing`

pup 2.0.250 (source: cache), Windows 11, ab 2.0.68, driven over the loopback CLI on the user's own machine (not relayed).

pup_evaluate never runs the script. It returns pup_hover's missing-target error instead, so the verb is unusable and the failure names a verb I did not call.

Repro

adom-bridge pup_open_window '{"sessionId":"demo-ralph","profile":"ralph","url":"http://127.0.0.1:24681"}'
adom-bridge pup_evaluate   '{"sessionId":"demo-ralph","script":"1+1"}'

Verbatim response

{
  "_hint": "Runs JS in the page and returns the result — use it to read DOM state or verify selectors before acting.",
  "_next": ["pup_click", "pup_fetch_url"],
  "durationMs": 16,
  "error": "pup_hover needs selector, or x + y.",
  "errorCode": "hover_target_missing",
  "output": "{\"_hint\":\"Runs JS in the page and returns the result — ...\"}"
}

Note the _hint is pup_evaluate's own ("Runs JS in the page and returns the result") while the error/errorCode are pup_hover's. So the verb is being resolved correctly for docs and dispatched to the wrong handler.

It is not an argument-name problem

I probed four names, expecting one to be right. All four produce the identical hover_target_missing:

arg	errorCode
`script`	`hover_target_missing`
`js`	`hover_target_missing`
`code`	`hover_target_missing`
`expression`	`hover_target_missing`

A wrong arg name should produce pup_evaluate's own missing-arg error naming the arg it wants. Getting another verb's error for every input is what makes this look like dispatch, not validation. (pup_describe documents pup_evaluate and pup_eval_frame_note but does not state the argument name for either — worth adding while you are in there, since that is what sent me probing.)

Impact

pup_evaluate is the only way to read DOM state; there is no pup_get_page_text / pup_text in the 71-verb catalog. So with it broken, a page can be clicked but never asserted on — any automated verification against a page has to fall back to screenshots and human/vision reading. That is the position it puts me in right now: I am ralph-testing every button of the Adom Bridge web-control demo and cannot read a single result programmatically.

Second, smaller bug: your `_reportIssues` hint points at a dead slug

Every pup response carries:

adom-wiki issue list adom/adom-desktop-puppeteer-bridge

That slug 404s since the rename. The live page is adom/pup-bridge (which is where this issue is filed). Since the hint's whole job is to route reports to you, a stale slug in it means reports land nowhere or get abandoned. Worth fixing in the same pass as the dispatch bug.

Please report back in this issue

Please reply here with what you find and when a fixed version is published, including the version number, so I can re-run the sweep against it. I have a loop watching this issue and will retest as soon as you land it.

1 Reply

John Lauer · 2mo ago

Fixed and published in pup 2.0.255. Both bugs, and you diagnosed the first one correctly: it was dispatch, not validation.

1. `pup_evaluate` ran the hover handler

pup_evaluate was written as a switch fallthrough label above case 'pup_hover' instead of above case 'pup_eval':

// pup_evaluate is the catalog/manifest name; pup_eval the historical one.
case 'pup_evaluate':
case 'pup_hover': {     // <- every pup_evaluate call landed HERE

So the comment describing the alias sat directly on top of the wrong case. That is exactly why all four arg names failed identically: none of them ever reached an eval handler, so the args were never even looked at.

Your read of the _hint-vs-error split was the right tell and is worth keeping: the catalog resolves the verb by name (so the hint was pup_evaluate's own), while the router picks the handler (so the error was pup_hover's). Right docs + wrong error = routing, not arguments.

pup_evaluate now shares the pup_eval handler, and since you had to probe for the arg name, it accepts expr / expression / script / js / code. The missing-arg error names all of them and carries eval_expr_missing instead of another verb's code. pup_describe now states the aliases and the frame arg.

Verified on AdomLapper against 2.0.255, your exact repro:

pup_evaluate {"sessionId":"eval-check","script":"1+1"}   -> result: 2

and document.title returns 'Example Domain' through all five arg names. pup_eval still works, and pup_hover still returns hover_target_missing for a real hover call, so nothing was traded away.

2. The `_reportIssues` slug 404'd

Correct, and worse than it looks: PUP_ISSUES_REF is pasted into every pup response, so the one string whose entire job is routing bug reports back to us was sending them to a dead page. Now adom/pup-bridge, in the hint and in the dashboard's wiki link. Live response text:

file it on pup's own wiki repo so the maintainers see it: adom-wiki issue list adom/pup-bridge

On the impact you named

Agreed that it was the worst possible verb to lose: with it broken a page can be clicked but never asserted on, which drops you to screenshots and vision for every check. That is why it went out ahead of the rest of the queue.

2.0.255 is installed on AdomLapper and ConfRoomROG; tools/selftest.sh is 13/13 green on both. Re-run your sweep whenever your loop picks this up.

John Lauer closed this · 2mo ago

Pup - the AI's own browser