A hand-written PDF writer using the 14 standard fonts (Helvetica, WinAnsiEncoding) maps characters outside its alphabet to "?". Intl.NumberFormat('fr-FR', { style: 'currency' }) uses U+202F (narrow no-break space) as the thousands separator and U+00A0 before the currency, so every amount of 1,000 or more prints like "26?000,00 $US" while small amounts look fine, which hides the bug in quick tests.

A URL parameter checked as a valid YYYY-MM-DD day in JavaScript (Date.parse plus a toISOString round trip) still crashes the page with "date/time field value out of range: 0000-01-01T00:00:00.000Z" when it is passed to a query as ${day}::date. JavaScript has a year 0. Postgres does not. For a date-typed parameter, postgres.js serializes the value through new Date(x).toISOString().

A time zone string validated in JavaScript with Intl.DateTimeFormat (it accepts 'CET', 'EET', 'WET', 'MET', 'PST', 'EST', 'IST', 'JST'...) and then passed to Postgres `timestamp AT TIME ZONE tz` gives different instants. In summer, '2026-07-10 14:30' AT TIME ZONE 'CET' is 13:30Z in Postgres but 12:30Z in JS. 'IST' is +02:00 in Postgres (Israel) but Asia/Calcutta (+05:30) in Intl. A POSIX string starting with a letter ('UTC+01:00', 'GMT-3') also passes a 'starts with a letter' check and Postgres reads its sign inverted.

Validating a time zone string in Node with `new Intl.DateTimeFormat(locale, { timeZone: tz })` and then passing the same string to Postgres (`ts AT TIME ZONE $1`) silently shifts results by twice the offset when tz is an offset like "+01:00", "+0100" or "+01". Recent Node versions accept these offsets in Intl as ISO offsets (UTC+1), while Postgres treats a bare offset in AT TIME ZONE as a POSIX zone spec, where the sign means west of Greenwich (UTC-1). No error is raised anywhere.

When testing a third-party embeddable JS snippet (tracker, widget) from a fake site served by `python -m http.server`, after changing the script the browser keeps running the OLD version: the static HTML pages are heuristically cached (Last-Modified, no Cache-Control) and the script itself is served with public max-age. Tests then show behavior of the previous version and look like a regression.

If you drive a modern React signup or login flow through a raw Chrome DevTools Protocol client (no Playwright), you hit several silent failures. el.click() from Runtime.evaluate does nothing on some submit buttons. Input.insertText on a 6-box one-time-code input leaves every box empty. Input.dispatchKeyEvent calls hang or take 30+ seconds. And after a click that triggers a client-side transition, reading the page right away still shows the old step, so you think the submit failed and act again.

A static HTML report embeds its data as a <script type="application/json"> block written by Python's json.dumps. One ratio computed as x/0 became float('inf'); Python serialises it as the bare token Infinity (allow_nan defaults to True) and Python's json.loads reads it back happily, so every server-side check passed. In the browser, JSON.parse throws "SyntaxError: Unexpected token 'I' ... is not valid JSON" on the first line of the page script, so nothing renders: empty chart, empty table, empty tiles, and no visible error unless you open the console.

A user wants a web app or PWA to track their location continuously ("know where I am all day"), but a browser can only read geolocation while the page is open and in the foreground. There is no background geolocation for websites or PWAs (especially iOS Safari) — the moment the tab is backgrounded or closed, tracking stops. Overpromising always-on tracking in a web app produces a broken, dishonest feature.

How to structure a non-trivial interactive application (100+ lines of JS, multiple UI states, user interactions) in a single HTML file without it becoming an unmaintainable mess. Single-file apps are ideal for personal tools, demos, prototypes, and utilities because they have zero build step, zero dependencies, work offline, and can be shared by email or dropped into any web server. But without structure, they quickly become spaghetti: DOM reads mixed with business logic, state scattered across DOM attributes and global variables, event handlers that directly manipulate other parts of the UI, and no clear flow of data.

When building bookmark managers, link grids, speed-dial pages, dashboard link sections, or any UI that shows a collection of website links, you need icons for each site. Options: (1) Manually download and host icons — tedious, doesn't scale. (2) Use a big icon library like FontAwesome — doesn't have website-specific logos. (3) Use each site's /favicon.ico — unreliable, CORS blocked, inconsistent sizes, some sites use .png or .svg. (4) Use a favicon proxy service — the right answer. Without icons, link grids look bland and are hard to scan visually. Users rely heavily on favicon recognition for quick navigation.