Closed general

ti.com badge paints a generic globe; ground truth favicon is the red TI Texas logo (no link rel=icon + hostile CDN)

John Lauer · 2mo ago ·closed by John Lauer

Repro 2026-08-16, evidence in shotlog channel six-states-final: v6-ti overlay descriptor claims favicon+adom: with an EMPTY host and the painted badge is the generic globe, while https://www.ti.com/favicon.ico serves a valid 48x48 image/vnd.microsoft.icon of the red Texas-outline TI logo (curl-verified, 15086 bytes). ti.com declares NO link rel=icon, so resolution rides the synthetic /favicon.ico candidate; the in-page fetch path appears to fail on TI's CDN and the fallback mislabels the result. Fix direction: when no link icons are declared, try the BRIDGE-side fetch (real UA, no CORS constraints) before or alongside the in-page fetch, and never record kind=page-favicon with an empty href. Mouser, Digikey and the wiki paint pixel-correct badges in the same session, so this is the no-declared-icon + hostile-CDN class only.

1 Reply

John Lauer · 2mo ago

Fixed in 2.0.211-2.0.212, pixel-verified on AdomLapper. Root cause was never the network: both fetch rails (bridge-side node fetch and the new Chrome-CDP Network.loadNetworkResource rail) were retrieving the correct favicon.ico bytes all along (15086B from ti.com, byte-identical to the bundled ground truth). The real bug: icoLargestPng only decodes PNG-in-ICO entries, and ti.com + mouser.com ship classic BMP-in-ICO (32bpp uncompressed DIB), so the correctly fetched icon was judged "unreadable" and silently discarded. 2.0.211 added honest per-rail logging, which exposed the lie in one loop; 2.0.212 added icoLargestDibRgba, a DIB-to-RGBA decoder (bottom-up BGRA rows, doubled-height XOR+AND mask, all-zero-alpha AND-mask fallback) feeding sharp raw pixels. The taskbar now shows the red TI Texas logo and the blue Mouser M; the dashboard strip LEDs are green. Proof shots in shotlog channel badge-truth.

John Lauer closed this · 2mo ago

Log in to reply.