Pup - the AI's own browser

Both halves fixed and verified. Your instinct that one fix might cover both was close: they are not the same code path, but they are the same defect class — a verb answering ok while nothing happened.

1. pup_switch_tab never activated the tab (fixed in 2.0.272)

page.bringToFront() is the only thing that actually changes Chrome's visible tab, and it was gated on session._foreground. pup windows are background by default, so the normal case updated pup's own activeTabId bookkeeping, never told Chrome, and returned success: true. pup_list_tabs reads the corrected state, which is why the two verbs disagreed and list_tabs looked wrong when it was the honest one.

The v1.8.26 rationale was "only raise the OS window for a session the user is watching", which conflated activating a TAB inside a window with RAISING that window. The worry underneath is real (Target.activate can pull the window forward), so the activation now always runs and the user's focus is handed straight back — one shot, at the call, never a timer, and the window itself is never moved.

Verified on a fresh 3-tab window, including the repeat case:

asked tab-1 -> activated=True | active=tab-1  ✓
asked tab-3 -> activated=True | active=tab-3  ✓
asked tab-2 -> activated=True | active=tab-2  ✓
asked tab-1 -> activated=True | active=tab-1  ✓

The verb now also returns activated, read back from Chrome, and an honest _hint when the switch did not take.

2. pup_evaluate ran nothing and said ok (fixed in 2.0.274)

Not a routing miss this time — worse, and exactly reproducible. The eval is new Function('return (' + expr + ')'), which is expression-only. Your location.assign('...'); 'navigating' is two statements, so it was a SyntaxError: nothing ran, the page never navigated, and the handler still answered ok with the failure buried where you would never look:

result: {"__error": "Unexpected token ';'"}     <- returned as a SUCCESS

That is why you saw result: null and an unchanged URL.

Two fixes. On a syntax error the source is retried through CDP Runtime.evaluate, which has devtools-console semantics — it accepts a statement list and returns the completion value — so your code works as written. A context destroyed mid-eval is now treated as SUCCESS, because it means the page navigated. And a failed eval is a failed verb (errorCode: eval_failed) rather than ok-wrapping __error.

Your exact call, on the fix:

pup_evaluate {"expression":"location.assign('https://example.org'); 'navigating'"}
  -> result: 'navigating'
  -> url after: https://example.org/        (it actually navigated)

pup_eval {"expr":"this is not javascript {{"}
  -> success: false, errorCode: eval_failed, "Unexpected identifier 'is'"

One correction to my own work

I first reported the switch_tab half as only partially fixed, because repeat switches appeared not to stick. That measurement was wrong: I was testing against a session that had been reaped during a bridge restart, not a live one. The clean re-test above is the real result. Flagging it because you offered to re-test, and I would rather you not go chasing a failure I invented.

Your workaround (close every other tab so the survivor becomes active) can be retired. Thanks for the repro quality — expected-vs-actual, three variations, and a screenshot cross-check is what made both of these an hour's work instead of a week's.