F339 Inside a Box Where the Get More Features Icon Belonged

Our pricing page had three empty boxes where icons should be, and on our own screens it looked perfect. I asked for a hotfix.

The agent that took the job found the cause. The three icons on that page, including the one next to “Get More Features!”, are drawn from an icon font, and the template behind the public event pages never loads the font’s stylesheet. Prod served the font files fine (the woff2 file was 57,764 bytes). The page just never requested them.

The page that hid its own bug

The agent could not make the boxes appear. Its screenshot of live prod showed the icon rendering, which hid the bug. My desktop has an older copy of that font (V14) installed as a system font, so the page looked fine here. Our first look at the live page said everything was fine, and it was not.

The fix was one line: a link to the icon font’s stylesheet in the template. On the local copy of the site the page now linked it and the browser reported the font as loaded. But the “after” screenshot looked exactly like the “before” one, for the same reason. The agent wrote that it had not observed an empty box on any machine, so it was not calling the bug fixed.

A second agent checked the work independently and came back with PASS WITH CAVEATS. It confirmed the ttf and svg copies of the font prod serves have all three icon codes. It could not decode the woff2 file, which is the one browsers load first, and nobody had seen the icons render from the web font. The ship ask listed what was not verified, and the next message put it on hold until three new screenshots were back.

Making a browser that couldn’t cheat

There was no BrowserStack or similar service, no credentials for one, and ssh to the other machine timed out. What got us unstuck was a browser that couldn’t see my installed fonts. Playwright’s Firefox was already on the machine, and Firefox has a setting that hides user-installed fonts. Whether that setting worked on this build was unverified, so the test had to prove itself first: the first screenshot had to be prod as it was, showing the empty boxes. If it didn’t, the rig was invalid.

It did show them. “Get More Features!” showed the missing-glyph box with F339 inside it. With the fix on the local site, the same tile showed the purple icon. With only the one stylesheet link injected into prod, the icon was drawn from prod’s own woff2, which closed the gap the verifier had left open.

I said “ok ship it.” The fix went live as a hotfix release. The agent re-ran the same Firefox setup against unmodified prod, and all three icons rendered. The earlier control run had shown boxes.

What we still don’t know

Only Firefox was run, so Chrome and Safari are unchecked. We also didn’t look at the other pages that now pick up the link in a browser. On timing, the agent traced the icons back to the release that first carried the pricing page rebuild, about 5 weeks ago, assuming that tag is the production release. If that holds, visitors without the font installed have been seeing boxes for about 5 weeks while our own screens stayed fine.

In the Firefox rig with user-installed fonts hidden, the “Get More Features!” tile showed a box with F339 inside it before the fix. After the ship, unmodified prod drew all three icons.

dxdev LESSON · paste into your AI coding agent
LESSON: Prove Your Test Rig Can Reproduce The Bug Before Trusting Its Fix Screenshot
SOURCE: dxdev.com/blog/looked-fine-on-my-screen
WHAT HAPPENED: The agent traced the bug to a template that never loaded the icon font's stylesheet, and the fix was a single link. Screenshots of live prod and of the fixed local site looked the same, because the desktop had an older copy of the font installed as a system font. The agent declined to call the bug fixed since it had never seen an empty box on any machine. A second agent returned PASS WITH CAVEATS because it could not decode the woff2 file browsers load first. The team then used Playwright's Firefox with the setting that hides user-installed fonts. The first screenshot had to show prod's empty boxes, or the rig would be invalid, and it did, with F339 inside the missing-glyph box. With the fix, the icon rendered from prod's own woff2, and after the hotfix shipped, unmodified prod drew all three icons.
THE RULE: Before trusting a fix verification, first show that your test setup reproduces the original failure on unmodified code. A setup that cannot show the bug cannot confirm the fix.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. The verification environment demonstrably reproduces the bug on the unfixed build, with a captured control screenshot or output, before any after-fix result is accepted.
      2. The test browser or machine is isolated from local state that can mask the defect, such as system-installed fonts, caches, or cookies.
      3. The ship request lists what remains unverified, such as untested browsers or undecoded assets, instead of reporting only the checks that passed.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.