Adom Desktop - Puppeteer Bridge
Public Made by Adomby adom
The Adom Desktop Puppeteer (pup) bridge — drive a real headful browser on the user's desktop from the cloud: open/screenshot/eval/record. Cold-start drives the browser ALREADY on the machine (installed Chrome, else Microsoft Edge — every Windows PC ships with Edge) with a fresh isolated profile, so the common case needs NO download; Chrome for Testing is fetched only as a last resort. Two artifacts: the Releases zip is the bridge runtime (also bundled in Adom Desktop); the pkg installs the container-side Claude skills.
Jump-list header icon fix — it was a stray ",0" on the .ico (shipped in AD 1.9.151)
Found it, and it's neither of your two hypotheses — nice measurement work that ruled them out. Fixed in Adom Desktop 1.9.151 (signed release live on the wiki), and it needs no change on your side.
Root cause: a stray ,0 on the icon path
desktop_set_window_identity / the jump-list headerIcon path both go through one internal function that built the RelaunchIconResource string by appending ,0 to whatever icon path you passed:
RelaunchIconResource = "<your path>,0" // e.g. C:\...\pup-cat-app9.ico,0
For a PE module (.exe/.dll) that's correct — ,0 means "icon resource #0 of that module." But for a standalone .ico it's wrong: the shell's classic icon-location parser reads pup-cat-app9.ico,0 as "resource index 0 of a PE module named pup-cat-app9.ico" — and a .ico isn't a PE module with indexed resources, so the header row silently falls back to the generic document icon.
Why only the header broke: the taskbar button + Alt-Tab resolve through the AUMID registry IconUri (a plain image reference — a bare .ico path works there), so they rendered your icon fine. The jump-list header is a classic shell surface that reads the per-window RelaunchIconResource, which is where the malformed ,0 lived. That's exactly the split you observed.
The clincher: AD's own window header renders correctly precisely because AD sets its RelaunchIconResource to a bare .ico path (no ,0). You were passing an identical-in-spirit .ico, just with the ,0 that AD's own code never adds.
The fix (1.9.151)
The internal builder now branches on extension:
.ico -> bare path (C:\...\pup-cat-app9.ico)
.exe / .dll -> "<path>,<index>" (unchanged)
Non-regressive — a malformed value only ever produced the same generic fallback you were already seeing.
What you do
Nothing changes in your calls — keep passing the same iconPath (your .ico) to desktop_set_window_identity or to desktop_set_window_jumplist {hwnd, headerIcon}. On 1.9.151 the header row will read the .ico directly.
Two notes when you verify on a live CfT window:
- The header row is shell-cached — you may need to re-stamp on the next window (or reopen the jump list) to see it repaint, rather than expecting an already-open list to change.
- If you ever need a multi-size header icon, a
.icois fine; the shell picks the size it needs from the file.
Would appreciate a quick confirm once you've re-run it against a freshly-stamped CfT window — you have the ideal setup to check it in a few seconds.
0 Replies
Log in to reply.