Closed general

Recorder HUD window: Chrome for Testing nag bar with a Download Chrome link, broken logo, duplicated title, tinted text, content clipped

John Lauer · 1mo ago ·closed by John Lauer

The recorder HUD window is in poor shape, and because it is branded "Adom Bridge Recorder" and ships inside ab's installer, it reads to a user as an Adom product window. John caught it; I had never opened it, which is my failure as much as a pup one.

Opened via pup_recorder_open on arav-rog just now. Window is 631 x 390 at (1901, 948). Screenshot attached, unretouched.

What is wrong, in the order the eye hits it:

  1. A "Download Chrome" link, in our product window. The Chrome for Testing banner sits across the top: Chrome for Testing v148.0.7778.97 is only... - truncated mid-sentence because the window is too narrow - next to a link that takes the user out of Adom entirely. --disable-infobars does not suppress this one; it is CfT's own nag surface, separate from the automation infobar.

  2. A broken-image placeholder where the Adom mark belongs, top-left of the panel. The asset exists in ab's installed bundle (bridges\puppeteer\recorder-icon.svg, 2591 bytes) but the live pup CACHE ships no recorder* files at all, so whatever the page resolves that src against is not finding it.

  3. Generic globe favicon and a light title bar over a dark panel. ab ships desktop_set_window_identity precisely for this - stamping appId, icon and display name on a window pup drives was the motivating case for that verb - and the HUD is not calling it.

  4. The title is rendered twice, in the title bar and again as the panel heading, about 40 px apart.

  5. Text is tinted arbitrarily. In "Adom Bridge Recorder" the B is a different colour from the rest, and the reason line "open the recorder HUD and actually look at it" comes out in three different greys. Whatever is highlighting that string is matching on something it should not.

  6. The first screenful does not fit. There is a scrollbar, and the first source row ("Screen") is cut off by the bottom edge. The window is smaller than its own initial content.

Worth saying plainly: 1, 3 and 6 are launch-time decisions (flags, identity, size) and 2, 4 and 5 are in the page. None of them need a user to report them - opening the window once shows all six.

I will take the ab-side half if it helps: if the HUD wants to stamp its window, desktop_set_window_identity {hwnd, appId, iconPath, displayName, relaunchCommand} is there and, as of 2.1.115, an empty string clears a field so a wrong stamp is undoable without restarting the window.

hud

3 Replies

John Lauer · 1mo ago

Follow-up, and it changes the ask: the answer here is probably to delete this window, not to fix the six things above. John's call, and I think the evidence backs it.

The HUD predates two things that have since made it redundant:

  1. ab 2.1.113 put a recording indicator on the screen itself - a 4x4 pixel teal square in the corner of the work area, up for the whole take. That is the "a recording is running" signal now. It survives a 10x speed-up, costs 16 pixels, and cannot be scrolled out of view or hidden behind another window, which a 631x390 Chrome window can.

  2. pup's own hints already route callers past this path. pup_screen_record_start answers:

    For a pup window/tab use pup_record_start (CDP screencast, background-safe). For a native no-browser MP4 use ab-core desktop_record_start. If you truly want the Chrome share picker path, re-call with confirmDesktopNotTabRecording:true.

    So the share-picker route is already gated behind an explicit confirm, with two better paths named ahead of it. The HUD is the surface for the option pup itself recommends against.

On ab's side the same decision was already taken: desktop_recorder_open / desktop_recorder_close are retired, and the verb now answers "the native recorder has no separate HUD". This is the matching cleanup on pup's side.

What deleting it costs, so the call is made with eyes open: the panel carries a SOURCES list with toggles. Chrome's own share picker is the consent surface for getDisplayMedia, not this window, so consent is not what would be lost - only a hand-toggle UI for a path whose hint already says to use something else. If anyone is relying on those toggles, that is worth knowing before it goes.

If it stays, the six defects stand. If it goes, they all go with it, and there is one less window shipping in ab's installer carrying the Adom name.

John Lauer · 1mo ago

John caught this again on 2026-09-14, on CfT 152 now (the nag bar reads "Chrome for Testing v152.0.7977.82 is only...", same truncation, same Download Chrome link). Two things worth recording:

  1. It was MY smoke test that put it back on his screen: tools/ab-smoke.sh called pup_recorder_open every gate run, so the broken HUD flashed up on his desktop whenever I ran the gate. Fixed: ab-smoke no longer opens the on-screen HUD (the pup_record_start/stop capture path already covers recording in the gate). That stops the parade; it does not fix the window.

  2. The deeper question John asked is the right one: why does this HUD exist at all now? ab ships a native recorder (desktop_record_start, 2.1.35+) that records a monitor plus system audio with no browser, no CfT, no HUD, and the demo-recording skill already says to prefer it and treat the pup HUD as a fallback only for a box without ab 2.1.35+. None of the fleet is on older ab. So the honest fix for all six defects here is not to reskin the HUD but to DEPRECATE the pup recorder HUD: point pup_recorder_open / pup_screen_record_* at ab's native recorder (or return a deprecation hint), and stop shipping a branded Adom window that nags users to download Chrome. Proposing we close this as "deprecate, do not restyle" unless there is a box that genuinely cannot use the native recorder.

Leaving it open for John's call on deprecate-vs-restyle.

John Lauer · 1mo ago

Superseded rather than repaired: as of 2.0.582 pup_record_start/stop/status/list delegate to ab's native recorder (desktop_record_window_* keyed on the window's hwnd: Windows Graphics Capture, hardware H.264 MP4, records a covered window live, works on the extension lane). The Chrome screen-share HUD this issue describes is deprecated; ab-smoke skips it and the lanes skill points every recording at ab's recorder. All six defects here are in a window pup no longer opens in the normal path. The pup_recorder_open verb still exists as a legacy fallback where ab's recorder is absent; if that fallback is ever needed on a real box, reopen this with the box name. Closing.

John Lauer closed this · 1mo ago

Log in to reply.