app

Pup - the AI's own browser

Public Made by Adom

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.

skillspuppuppeteerbrowseradom-bridgebridgepup-bridge
Overview Files Skills Discover Packages Releases Dependencies Issues17 Breadcrumbs Pull Requests1 Activity
Closed general

Taskbar progress fill does not render on Windows 11 25H2 (26200); attention tint on background-born windows clears only on a user click

John Lauer · 2mo ago ·closed by John Lauer

Taskbar progress does not render on Windows 11 25H2 (build 26200.9168), for any app

Measured on arav-rog on 2026-09-05 while reviewing the pup demo take.

What was tried, all with a screenshot of the taskbar 2 to 11 s after the call:

  1. pup_progress {mode:"value", value:30|50|60|75}, indeterminate, error on a pup window (thread tile, aumid stamped). ab answers applied:["progress:normal"]. Nothing drawn.
  2. ab desktop_taskbar {hwnd, progress:{state:"normal", value:0.5}} on the stock Chrome for Testing button and on Notepad. Nothing drawn.
  3. A plain PowerShell ITaskbarList3 COM call (HrInit, SetProgressState TBPF_NORMAL, SetProgressValue 50/100) on the Notepad window, held 14 s. Nothing drawn.

So it is not pup, not ab: this Windows build paints no taskbar progress fill, at least with this taskbar configuration. The verbs still run and report success, so a demo or a skill must not promise the pixels.

Also measured, same session: a window born in the background (pup's default) gets the Windows 11 "needs attention" tint on its button (salmon background, red underline). desktop_flash_window {stop:true} and a programmatic raise do not clear it. Only a real click on the taskbar button clears it. The demo driver now opens the window in the background and clicks its button, as a user would.

Actions

  • tools/pup-demo.py: caption states the capability, does not claim the fill (done).
  • pup-taskbar-states and pup-settings skills: add a line that some Windows 11 builds draw no taskbar progress and that the attention tint of a background-born window clears only on a user click.
  • Re-check on a 24H2 box (winvm) and on AdomLapper to bound the affected builds.

2 Replies

John Lauer · 2mo ago

Partial update. The second half of this issue (the attention tint on background births) is resolved at the source in 2.0.449: new windows are created with the DevTools focus:false option, so Chrome never requests the foreground and Windows never flags the button; 2.0.450 adds the winAttentionFlash setting (default off) for anyone who wants the classic behaviour back. Measured on arav-rog with KiCad in the foreground: plain birth tinted, focus:false birth clean, foreground unchanged. The first half (no taskbar progress fill on 25H2 build 26200 for any app) is still Windows-side and stays open.

John Lauer · 1mo ago

Closing with a second measurement, 2026-09-19, AdomLapper, Windows 11 25H2 build 26200.9457 (newer than the 26200.9168 in the report): pup_progress {mode:'value', value:60} on a stamped thread-tile window answered applied:true, and a capture of the taskbar strip 3 s later shows the pup button with no progress fill at all (zoomed crop read by the AI). Same result as arav-rog on 2026-09-05: this Windows build paints no taskbar progress for any app; the verbs run and report success and must not promise the pixels. Documented in pup-taskbar-states, pup-taskbar-progress and pup-settings ('Measured limits', pup-bridge#99). The second half, the attention tint on background births, was fixed at the source in 2.0.449 (focus:false creation) and is moot since 2.0.641 (windows are bottomed the instant they first show). Reopen if a later 25H2 build starts painting the fill.

John Lauer closed this · 1mo ago

Log in to reply.