DEV Community: Vladimir Elchinov

Your Bug Reports Do Not Say Which Fields Were Measured and Which Were Typed

Vladimir Elchinov — Tue, 22 Sep 2026 12:57:22 +0000

Two tickets arrive. Both have an Environment field. Both say Chrome 141, macOS.

One of them was read off the browser by a script. The other was typed by a person recalling what they think they use. In your tracker they are the same eleven characters, in the same field, in the same font.

You are going to trust them equally. One of them does not deserve it.

Typed values fail in a specific direction

If typed fields were merely noisy, this would not matter much: sometimes right, sometimes wrong, average out over enough tickets.

They are not noisy. They are wrong in a systematic way, and the bias runs exactly opposite to what you need.

People report the browser they chose, which on an iPhone is not the browser that rendered the page, because every iOS browser is WebKit underneath.
People report "latest", which is a statement about their intentions rather than their build. Chrome had three live major versions in one week this month.
People report the time by looking at the clock that is wrong, which is the same clock that produced the timestamp you are trying to match against your logs.

In each case the person is being careful and truthful, and the answer is still wrong. Worse, the answer is most wrong precisely in the cases where the field would have been decisive. A correctly typed "Chrome 141" tells you nothing you needed; an incorrectly typed one costs you the afternoon.

Provenance is part of the value

The fix is not more fields or better form copy. It is that a value and how you got it are one piece of information, and splitting them throws half away.

{
  "browser":  { "value": "Chrome 141.0.7390.55", "source": "measured" },
  "os":       { "value": "macOS 15.6",           "source": "measured" },
  "steps":    { "value": "...",                   "source": "stated" },
  "started":  { "value": "2026-09-22T13:05:00Z",  "source": "stated" }
}

Four fields, and a reader now knows which two to argue with. Nothing about the values changed. What changed is that the ticket stopped presenting a guess and a reading as the same kind of thing.

I did not come up with that framing. A reader named Sven Andreas put it in a comment on an earlier post here, describing an open-source reporting client he is building: it reads the values the project declares, shows each one to the reporter before sending, and labels it as measured rather than typed. That last clause is the part worth stealing. Collecting automatically is common. Saying so in the artefact is not.

The measurement you get for free afterwards

Once the two are distinguishable, you can compare them, and the comparison is the useful bit.

Ask for the browser and measure it. Then count how often they disagree. If the typed answer matches the measured one 95% of the time, stop asking, the question is noise in your form. If it matches 60% of the time, you have just learned that the field has been quietly poisoning triage for years, and roughly how much.

You cannot run that comparison on a form that merges them into one box, which most forms do, including the default one in most trackers.

The cheap version

You do not need a schema change to start.

Keep them as two fields, not one. "Browser (detected)" and "Browser (as reported)". Let them disagree on the ticket rather than resolving the disagreement in the form, which is the moment the information is destroyed. Whoever picks the ticket up can see both, and the gap between them is often the fastest read on the whole report: a person who believes they are on Safari 26 while the string says 27.0 has just told you what kind of week you are having.

And for the fields that can only ever be stated, steps, expectations, what they were trying to do, mark them as such and stop apologising for them. A stated field is not a worse field. It is a different kind of claim, and the only failure is presenting it as the other kind.

The unlabelled ticket is the one that costs you, because it asks you to trust everything on it equally, and you will.

Your Error Tracker Has Never Seen Your Worst Failures

Vladimir Elchinov — Mon, 21 Sep 2026 12:57:24 +0000

Every in-page monitoring tool has the same blind spot, and it is not a bug in any of them. Error trackers, analytics, session recorders, the browser extension I work on: all of them are JavaScript that runs on your page.

So none of them can tell you anything about the times your page did not run.

The failures that leave no trace in the browser

Think about what the user sees in each of these:

DNS does not resolve. DNS_PROBE_FINISHED_NXDOMAIN.
The connection is refused or times out. ERR_CONNECTION_REFUSED.
The certificate does not validate. NET::ERR_CERT_AUTHORITY_INVALID, and a full-page warning.
The CDN returns a 502 from its own error page, not yours.
A corporate proxy or a DNS filter blocks the domain outright.

In every one of them the browser shows its own page. That page is not your site. Your HTML never parsed, your bundle never downloaded, your snippet never initialised, and there is no place for a window.onerror handler to exist, let alone fire.

Which means your error tracker records nothing. Not a zero. Nothing: no event, no session, no user. The dashboard does not go red. It goes quiet in a way that is indistinguishable from everybody having a lovely time.

The half that surprises people is the server side

The instinct is that at least the server knows. Often it does not.

A DNS failure never produces a connection, so nothing reaches you at all. A blocked domain is the same. A refused connection never becomes a request. A TLS handshake that fails never becomes an HTTP request either, so it does not appear in your application's access log, which only ever sees requests that got that far. Depending on how the terminating proxy is configured, a handshake failure may appear in its error log, which is a different file that most teams read only when they already suspect something.

So for this class of failure you have two instruments, and both are pointed the wrong way:

in-page monitoring   → requires your page to run     → it did not
application logs     → require a completed request   → there was none

The overlap of those two blind spots is the set of users who could not reach you. They are, by definition, the users least represented in every number you have.

This is survivorship bias with a build step

Your metrics describe the people who got in. Uptime checks from a monitoring service describe a machine in a datacentre that has clean DNS, no proxy, a correct clock and a fresh certificate store. Both are useful. Neither is evidence about the person whose employer's MITM proxy rejected your chain this morning.

That gap has a shape worth remembering: the failures that are invisible to you are disproportionately the ones that are specific to the user rather than to your server. A clock that is a year out. A resolver that is being filtered. A network that intercepts TLS. Your server is fine for everyone else, your instruments agree, and one person is locked out with a red screen.

What actually finds them

Three things, none of which is your error tracker.

Check from outside, from more than one place. Not a browser you have used before: one that has never fetched your intermediate certificate, on a network that is not yours. External checkers exist precisely because your own machine is a contaminated instrument.

Read the layer below the application. Handshake failures, connection resets and blocked requests live in the proxy or load balancer logs, not the app's. If you have never looked at that file, you do not know whether it is empty.

Take the report seriously when it arrives. This is the awkward one. For this class of failure the only signal that exists is a human being telling you, and they will tell you badly, because there is nothing for them to copy. No console, no network tab, no error id. Just a red page and a sentence.

That is the part worth internalising. Most of the time, "the report is vague" is a process problem you can fix by asking for more. Here it is a physical constraint: the browser refused before anything of yours existed, so there is nothing to collect, and the vague sentence is the whole of the evidence that will ever exist.

Which changes what to do with it. Not "please reproduce it with the console open". Instead: what exact words were on the screen, what time does their device say it is, does it happen on mobile data. Three questions that work precisely because they do not assume your page ever loaded.

Your dashboards will still be green while you ask them.

We Shipped a Week of Posts With Images. We Cannot Prove a Single Image Arrived.

Vladimir Elchinov — Fri, 18 Sep 2026 12:57:12 +0000

Our social posts go out through a script. It uploads an image, gets a media id back, then creates the post with that id attached. Every run prints the URL of the post it made, and for a week I reported those URLs as "posted, with the cover".

Then a colleague found that a video post of theirs had gone out as plain text. The API had accepted it. It had returned a perfectly normal id. The clip was simply not there.

So I went to check ours, and could not. Which is the part worth writing down, because neither half of that is unusual.

Two calls, one of which cannot fail

The shape is everywhere: upload the thing, then reference it.

POST /media        -> { media_id: "1234" }
POST /posts        { text: "...", media_ids: ["1234"] }  -> { id: "5678" }

The second call validates what it was given. The id is a well-formed string, so the request is well-formed, so the post is created and you get an id back. Whether that media id points at anything usable, whether the upload finished processing, whether your code even put the field in the payload on this code path: none of that is the create call's business.

You get a 200 and an identifier either way. The identifier is proof that a post exists. It is not proof of what is in it.

In our case the immediate cause was mundane. The --video flag reached only one branch of the posting code; the other branch accepted an image parameter and silently ignored a video one. A missing field is not an error to an endpoint that treats every field as optional.

Why "it returned an id" feels like proof

Because for single-call operations it nearly is. POST /users returning an id does mean a user exists with the fields you sent, because there was only one call and one set of fields.

The intuition breaks the moment an operation spans two calls, and it breaks silently, because nothing in the second response mentions the first. There is no media_attached: false. The response shape is identical.

That is the same reason a compound operation needs a different kind of assertion:

const { id } = await post({ text, media_ids: [mediaId] });

// Not done yet. Read it back and assert on the property you wanted,
// not on the fact that something was created.
const check = await get(`/posts/${id}?expansions=attachments.media_keys`);
if (!check.data?.attachments?.media_keys?.length) {
  throw new Error(`post ${id} went out without its media`);
}

Four lines. The reason they did not exist is that everything looked like it worked.

The rule I actually changed

My first instinct was to add "verify the attachment after posting" to the runbook. A colleague's phrasing was better, and it is the thing I would pass on: do not claim the image attached when what you have is an id.

The difference is where the burden sits. "Verify afterwards" is a step you can forget, and forgetting it leaves the false claim in place. "Do not claim it" makes the unverified state the default, so forgetting to check means saying less, not saying something untrue. One of those degrades safely.

So the reports now say "posted". Not "posted with the cover", until there is a read-back that proves it. Our read-back is currently blocked by an unrelated signing bug in the same script, which is its own small lesson: the verification path and the action path are different code, and the one you never run is the one that is broken.

Where this stops being about posting

Every bug report that contains the phrase "and it said it worked" is this.

The person clicked submit. Something returned a success state. A green tick appeared, or a confirmation page, or a toast. None of that is evidence the operation completed, because the confirmation was rendered by the same layer that would have needed to know it failed, and often that layer only knows a request was accepted.

Which means the sentence "I submitted it and it said it was fine" carries about as much information as our tweet id did. It is real, the person is not mistaken about what they saw, and it says nothing about whether the thing arrived.

The useful version of that report is not a better description of the confirmation. It is the request and the response that produced it, captured at the time, from the machine where it happened. Everything else is a screenshot of a green tick.

We had a week of green ticks. They were all genuine, and I still cannot tell you what was in the posts.

"It Broke Around 3pm" Is Not a Timestamp

Vladimir Elchinov — Thu, 17 Sep 2026 12:57:37 +0000

A user tells you the checkout failed around 3pm yesterday. You open the logs, search 14:30 to 15:30, find nothing unusual, and reply that you cannot see anything on your side.

Three separate things in that sentence can be wrong, and none of them is the user being careless.

The three ways their 3pm is not your 3pm

They are in a different timezone from your logs. Yours are UTC, because everybody's are. Theirs is wall-clock local, and they did not say which. Half of Europe is one hour off UTC in winter and two in summer, so "3pm" from an unspecified reporter is a window of at least a day if they are global, and an hour wrong if you guessed their country right and the DST boundary wrong.

Their clock is wrong. Not metaphorically. A device whose time sync is off, a VM resumed from a snapshot, a phone that has been in aeroplane mode since Tuesday, a desktop where someone set the clock by hand to make a licence work. Date.now() in the browser reads that clock. MDN puts it plainly: Date.now() "may have been impacted by system and user clock adjustments, clock skew, etc. as it is relative to the Unix epoch and dependent on the system clock."

"Around" is doing real work. People round to the nearest interesting number. "Around 3" covers 14:40 to 15:20 in practice, and if the thing they remember is "just after lunch", it covers two hours.

Stack those and your one-hour log search can miss the event by half a day. You conclude nothing happened. Something happened.

What the browser can tell you instead

All three are solvable, but only by something running on their machine at the moment it breaks, because every one of them is a property of their machine and not of their memory.

function timeFacts() {
  return {
    // Their clock. Wrong sometimes, but it is the clock that produced
    // any timestamp they will ever quote at you, so capture it as-is.
    clientTime: new Date().toISOString(),

    // What their calendar thinks, so "3pm" can be resolved.
    timeZone: Intl.DateTimeFormat().resolvedOptions().timeZone,  // "Europe/Madrid"
    offsetMinutes: new Date().getTimezoneOffset(),

    // Monotonic, immune to clock changes: MDN, "its current time never
    // decreases and isn't subject to adjustments". Useless across machines,
    // perfect for ordering events within one session.
    sinceLoad: Math.round(performance.now()),
  };
}

The fourth value is the one that closes the case, and it does not come from the browser at all. Every HTTP response carries a Date header, which is the server's own time, in GMT, formatted by the server. Read it off any same-origin response:

const res = await fetch('/api/ping');
const serverTime = new Date(res.headers.get('Date'));   // their request, your clock
const skewMs = Date.now() - serverTime.getTime();       // how wrong their clock is

(Cross-origin you have to expose it with Access-Control-Expose-Headers: Date first.)

Now "around 3pm" becomes an instant on your clock. Their timestamp, plus the skew you measured, lands in your logs. If the skew is forty minutes, you know that before you search, instead of concluding after an hour that the bug is imaginary.

Why this keeps happening

Because the report is a memory, and memories are in local wall time with the precision of somebody who was not expecting to be asked.

You can write a longer form. "Please give the exact time and your timezone" produces a more confident wrong answer, because the person reads their own clock, which is the clock that was wrong. There is no phrasing that fixes a device whose time is off by forty minutes, and no amount of care from a reporter who has no reason to suspect their machine of lying.

The only reliable version of this information is measured at the moment of failure, on the machine where it failed, and sent along with everything else. Four fields, one fetch, and a class of "cannot reproduce, nothing in the logs" simply stops happening.

Worth the twenty minutes next time you build a report form. The alternative is searching the wrong hour and believing the result.

"Send Me the Network Tab" Asks for Evidence That No Longer Exists

Vladimir Elchinov — Wed, 16 Sep 2026 12:58:01 +0000

Somebody reports that your app failed to load their dashboard. You send the standard reply: open DevTools, go to the Network tab, reproduce it, screenshot what you see.

They do exactly that. The screenshot shows a healthy list of requests, all 200s, nothing red. So you close the ticket as not reproducible, and they get annoyed, because the page really was broken.

Both of you are looking at evidence that was collected after the event.

The panel is not a recorder, it is a listener

From Chrome's own Network panel reference: "By default, DevTools records all network requests in the Network panel, so long as DevTools is open." And from the panel's own getting-started page: "DevTools only logs network activity while it's open."

There is no buffer behind that. The Network panel is not reading a log the browser was keeping anyway; it attaches when you open it and records from that moment. Everything the page did before, including the request that failed, was never written down by anything.

So the instruction "open DevTools and reproduce" is asking for the second occurrence of the bug, not the first. Which is fine when the bug is deterministic, and useless when it is not, and the whole category of bugs that arrive as "it worked when I tried again" is exactly the non-deterministic kind:

A cold cache. The first load fetched something the second load had.
A race at startup, which the second attempt loses less often because a connection is already warm.
An expired token that the failing request refreshed as a side effect, so the retry is authenticated and the original was not.
A rate limit that has since reset.
Anything that only happens on the first navigation of a session.

Each of those reproduces perfectly, once, on somebody else's machine, and leaves no trace by the time the panel is listening.

Then the log clears itself

The second half is worse, because it discards evidence the panel did record.

Chrome again, on the same page: "To save requests across page loads, check the Preserve log checkbox on the Network panel." It is off by default. Any navigation clears the list. The Console behaves the same way: "By default the Console clears whenever you load a new page."

Now think about what a login bug looks like. The user submits the form, gets bounced through two redirects, lands somewhere wrong. By the time the final page has settled, the network log contains that final page's requests and nothing else. The 302 chain you actually need is gone. The user screenshots what is on screen, which is a perfectly healthy page load, and you conclude that the POST never happened.

The same applies to any bug whose last act is a navigation: a failed checkout that redirects to an error page, an OAuth callback, a form that reloads on submit. The evidence deletes itself at the exact moment the user reaches for the camera.

What to ask for instead

If you are going to ask a person to do this, ask for all of it, in order:

Open DevTools before the bug, not after.
Network panel, tick Preserve log. Console settings, tick Preserve log there too.
In Network settings, tick Capture screenshots if the bug is visual, which gives filmstrip frames lined up against the requests.
Now reproduce.
Right-click any row, Save all as HAR with content rather than screenshotting. A screenshot of a list is a list; a HAR is the requests.

That is five steps and three settings that a non-technical reporter will not complete, which is the honest reason most teams send the one-line version and accept the useless screenshot.

The part that does not have a workaround

Steps 1 through 5 all assume the person knew the bug was coming.

Nobody does. The failure happens, and then someone decides it is worth reporting, and by then the only instrument that could have recorded it was switched off. You can ask them to reproduce, and for a deterministic bug that works. For everything else, the report you needed had to be collected by something that was already running when the page broke, which is a different requirement from anything a support reply can contain.

Worth knowing before the next "cannot reproduce". The person did not fail to gather evidence. The evidence was never gathered, by anyone, including you.

Every Browser on an iPhone Is Safari, and the Bug Report Will Not Say Which One

Vladimir Elchinov — Tue, 15 Sep 2026 12:58:02 +0000

Safari 27 shipped on Monday with iOS 27. By the weekend most iPhones will be on it, and most of their owners will not know. That is the ordinary story of a browser release. The less ordinary part is how many "browsers" that one update just changed, and how badly a bug report describes any of them.

One engine, many names

Apple's App Store Review Guidelines, 2.5.6: "Apps that browse the web must use the appropriate WebKit framework and WebKit JavaScript." An entitlement for an alternative engine exists for the EU and Japan; outside a handful of apps in those markets, the rule is the rule. So:

Chrome on iPhone is WebKit with Chrome's toolbar. Same for Firefox, Edge, Brave, Opera.
The browser inside Instagram, Facebook, Slack, Gmail, TikTok and LinkedIn is WKWebView, a system component. It is WebKit with whatever settings the app chose.
"Open in Safari" from those apps is the actual Safari.

All of those updated overnight with iOS 27, because WebKit is part of the OS, not part of the app. The Instagram in-app view that renders your page got scroll anchoring and eight Content Security Policy fixes on Monday, and Instagram shipped nothing.

When a report says "Chrome on my iPhone", the engine is Safari's, and reproducing it in Chrome on your desktop reproduces the wrong one. When it says "I opened it from Instagram", the engine is Safari's too, but the feature set is not: no extensions, no address bar, the app's own cookie jar, and often no way to get to the tab in any other browser.

What the user agent actually tells you

The reporter cannot tell you which of those they were in. The user agent string can, if you know its shape. Three tokens do most of the work:

export function iosSurface(ua = navigator.userAgent) {
  if (!/iPhone|iPad|iPod/.test(ua) && !isIpadPretendingToBeAMac()) return null;

  if (/CriOS\//.test(ua))  return "chrome-ios";     // still WebKit
  if (/FxiOS\//.test(ua))  return "firefox-ios";    // still WebKit
  if (/EdgiOS\//.test(ua)) return "edge-ios";       // still WebKit

  // Safari names itself twice: "Version/27.0 ... Safari/604.1".
  // A WKWebView sends neither token. That absence is the whole signal.
  if (/Version\/[\d.]+.*Safari\//.test(ua)) return "safari";
  return "in-app-webview";
}

// Since iPadOS 13, Safari on an iPad asks for desktop sites by default and
// says it is a Mac. The touch points give it away.
function isIpadPretendingToBeAMac() {
  return navigator.platform === "MacIntel" && navigator.maxTouchPoints > 1;
}

Two of those lines are the ones that cost people afternoons.

The missing Safari/ token. A WKWebView user agent reads something like Mozilla/5.0 (iPhone; CPU iPhone OS 27_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148. No Version/, no Safari/. Most user agent parsers, handed that, print "Safari" anyway, because WebKit on iPhone is Safari as far as they are concerned. So your analytics say Safari, your error tracker says Safari, and the failure only happens inside the Instagram browser, where the app has disabled something you rely on. Apps do append their own markers (Instagram, FBAN/FBIOS, LinkedInApp), but not all of them, and not consistently; the absent tokens are the reliable test.

The iPad that says it is a Mac. A report of "Safari on Mac, buttons do not respond" can be an iPad. It sends a Macintosh; Intel Mac OS X user agent, gets your desktop layout at 1024 points wide, and then tries to tap hover menus with a finger. Every hover-only interaction on the page is broken for that user, and the report will say Mac. maxTouchPoints is the only honest witness.

One more thing the string will never tell you: navigator.userAgentData, the structured replacement, is undefined on every one of the surfaces above. WebKit has not shipped it. Code that feature-detects the new API and treats its absence as "an old browser" has just classified every iPhone on earth as old.

Why this is a reporting problem before it is a detection problem

The function above is useful in your own telemetry. It is useless in the moment that matters, which is when a person types "does not work on my phone" into a form and hits send.

That person cannot see the user agent. They do not know that the Chrome icon they tapped opens Safari's engine, or that the link they followed from a Slack message never left Slack. They will answer "Chrome" or "Safari" or "my iPhone" in good faith, and every one of those answers points the developer at the wrong reproduction.

So the report has to carry the string itself, captured from the page at the moment of the failure, along with the viewport and the touch points. Not because the reporter should have known, but because they could not have. Anything that asks them to describe their browser is asking a question they are structurally unable to answer correctly on iOS, and this week, with one engine update landing on every surface at once, the wrong answer costs a reproduction that will never succeed.

Your `window.onerror` Handler Has Never Seen a Rejected Promise

Vladimir Elchinov — Mon, 14 Sep 2026 12:57:49 +0000

There is a class of failure that most hand-rolled error tracking has been blind to since promises arrived, and the reason is structural rather than a bug: a rejected promise is not an exception. It is a value. Nothing is thrown, so nothing is caught, and the handler you wired up in 2015 to window.onerror sits there reporting a healthy page while the async half of your application fails quietly beside it.

Two channels, not one

The browser has two separate mechanisms for telling you something went wrong, and they do not overlap.

Synchronous exceptions go through window.onerror (or an error event listener). Anything thrown and not caught in a script, an event handler, a timer callback, arrives here with a message, a filename, a line and column, and the Error object.

Rejected promises with no handler go through a different event entirely. MDN's wording:

The unhandledrejection event is sent to the global scope when a JavaScript Promise that has no rejection handler is rejected.

Note the phrase no rejection handler. A promise rejection is not an error condition in JavaScript. It is a normal state a promise can be in, and it only becomes a problem when nothing is listening. The runtime waits until the end of the current task to see whether a .catch() turns up, and if none does, it fires unhandledrejection. Not error. Nothing is thrown at any point.

Which means this catches nothing from a failed fetch, a rejected async function, or an await inside code with no try:

window.onerror = (message, source, line, col, error) => {
  send({ message, source, line, col, stack: error?.stack });
};

And this is what was missing:

window.addEventListener('unhandledrejection', (event) => {
  send({ reason: event.reason });
});

Why it is worse than a missing handler

Three things about the second channel make it easy to get wrong even once you know it exists.

reason can be anything. A synchronous throw almost always carries an Error, so there is a stack. A promise can be rejected with a string, a number, undefined, a response object, whatever somebody passed to reject(). event.reason.stack is a property access on a value that may not be an object. Half the rejections in a real codebase carry no stack at all, because the code that produced them never constructed an Error.

preventDefault() silences it. The event is cancelable, and MDN is explicit about what cancelling does:

Allowing the unhandledrejection event to bubble will eventually result in an error message being output to the console. You can prevent this by calling preventDefault().

Some libraries do exactly that, to keep the console clean. If one of them loaded before your tracking did, and it calls preventDefault() without forwarding, your handler runs but the console entry that would have alerted a developer never appears. The failure is now recorded nowhere a human looks.

The timing is different. An error event fires at the throw. unhandledrejection fires at the end of the task, after the rejection has propagated through whatever chain it was in. The stack, if there is one, points at where the promise was created, not at where it failed to be handled. For a fetch that rejected because the network dropped, that is a frame in a helper that wraps every request, which tells you which of two hundred calls failed exactly as well as a 404 page tells you which file is missing.

Where this actually bites

The pattern is a page that works, with a feature that silently does not.

A button calls an async function. The function awaits a request. The request fails. Nothing was thrown synchronously, so window.onerror is not involved. The promise rejects with a TypeError: Failed to fetch, nothing catches it, and the button does nothing. The user sees a button that does nothing. The error tracker sees a healthy page.

The user reports: "the save button is broken". The developer clicks save, it works, and closes the ticket. There was an error, it had a message, and it went down a channel nobody had connected.

What to check

Open your production page, and in the console:

Promise.reject(new Error('canary'));

Then look at what your tracker recorded. If nothing arrived, every async failure on that page has been arriving the same way for as long as the tracking has existed. If something arrived but with no stack, that is the reason-is-not-an-Error problem, and it is worth normalising at the boundary:

const reason = event.reason instanceof Error
  ? event.reason
  : new Error(String(event.reason));

And if your handler runs but nothing shows in the console, something upstream is calling preventDefault(), and you have a library to find.

None of this is exotic. It is the difference between the errors that were thrown and the errors that merely happened, and only one of those was ever wired to the thing you check.

"Cannot Reproduce" Often Means "Different Build", and Four Places That Happens

Vladimir Elchinov — Fri, 11 Sep 2026 12:32:45 +0000

I published something this morning saying a feature had shipped. It had not. The work was real, the commits were real, and they were sitting on a branch that was not main. I had read a git log without checking what the repository was checked out to, and written an announcement off the answer.

The narrow lesson is boring: look at your branch. The general one is not, because the same gap sits underneath one of the most common ways a bug report dies.

"Works on my machine" has a version axis

The environment version of that sentence is well worn: different OS, different data, no network latency, a case-insensitive filesystem. That is real and it is covered everywhere.

The version axis gets much less attention, and it is simpler to fall into. You are not running the code your user is running. There are at least four places the two can diverge, and each one is invisible from where you sit.

Your working tree is not the default branch. The commit exists. It is in your log. It is not in anybody else's build. This is the one I hit today, and the tell is that everything looks merged when you are standing on the branch that has it.

The default branch is not released. Merged is not published. There is a release train, a store review, an approval queue, a deploy window. For a browser extension the gap between "merged to main" and "available to users" is measured in days and decided by somebody else's reviewer.

Released is not installed. Auto-update is a schedule, not an event. A fraction of your users are on the previous version at any moment, and the fraction is larger than you would guess for anything installed rather than served.

Installed is not running. This is the one people miss entirely. Chrome stages an extension or browser update and applies it at restart. A tab that has been open for a fortnight is running what it launched with, no matter how many times the update was fetched in the background. The person reporting your bug may have the fix on disk and not in memory.

Why this closes tickets that should stay open

"Cannot reproduce" is one of the most common ways a report ends. The path to it is short:

A user reports something broken.
You check out the default branch, run it, and the problem is not there.
You close the ticket, reasonably, because you looked.

Step two is where the version axis hides. You ran a build nobody outside your machine has. If the bug was fixed last week on a branch, or fixed on main but not released, or released but not yet installed, or installed but not yet running in their tab, then both of you are right and the disagreement is about which program you are each talking about.

Nothing in the report tells you that, because the report contains what the user could see, and a version number is not something anybody thinks to look up while annoyed.

The fix is boring and it is the version

Make the report carry the build, automatically, and treat it as a required field rather than a nice-to-have. The extension or app version, the browser version, and ideally the commit the server was running when the request happened.

And be careful with "latest". Users say "latest" and mean "I have not deliberately stopped updates". It is not a version, and treating it as one is how you end up debugging a build nobody is on.

If you own a browser extension, chrome://extensions shows the installed version, and it can disagree with what is running in a tab that has been open a while. That is worth asking about explicitly rather than assuming a restart has happened.

The uncomfortable part

Our machines agree with us. You check out the branch you were working on, and it has your work. You run main, and the bug is gone. Every check you can run from where you are standing confirms what you already believe, which is exactly the shape of a mistake you do not catch.

I wrote an announcement this morning that was confidently wrong, and every command I ran while writing it told me I was right. The only thing that fixed it was somebody who had the actual state of the world telling me otherwise.

That is what a good bug report is: somebody handing you the state of the world from where they are standing, because from where you are standing it looks fine.

"Script error." Is Not an Error. It Is Your Error Tracker Being Told to Shut Up.

Vladimir Elchinov — Thu, 10 Sep 2026 12:29:39 +0000

If you have ever opened your error dashboard and found a pile of entries reading Script error. with no message, no stack, and line 0, column 0, you have probably filed it under "browser noise" and moved on.

It is not noise. It is a real exception, thrown by real code, with everything useful deliberately removed before it reached you. And the class of code it happens to is the class most likely to break in ways you did not anticipate: the scripts you serve from somewhere other than your own origin.

What is actually happening

The HTML specification gives every classic script a muted errors boolean. The wording is worth reading directly:

if true, means that error information will not be provided for errors in this script. This is used to mute errors for cross-origin scripts, since that can leak private information.

And the condition that sets it:

Let mutedErrors be true if response was CORS-cross-origin, and false otherwise.

That is the whole mechanism. A script fetched from another origin, without CORS, is a script whose exceptions arrive at window.onerror stripped: a fixed message, no filename, no line, no column, and error set to null so there is no stack to walk.

The reasoning is sound. An error message can contain anything the script was holding when it threw. If any page could load any cross-origin script and read its exception text, that is a side channel for reading things the origin never agreed to share. So the browser closes it by default.

The problem is not the rule. The problem is that almost nobody realises the rule applies to them.

Who this actually hits

Not "third-party widgets". You.

The moment your own bundle is served from a CDN on a different hostname than your page - which is most production setups, and is exactly what every performance guide tells you to do - your application's own JavaScript is cross-origin to your application. Every uncaught exception it throws is a candidate for muting.

Which produces the failure mode worth naming: your error tracking still works. You keep getting errors, because inline scripts and same-origin scripts report normally. You just quietly stop getting them from the one bundle that contains most of your code. Nothing announces the gap. Your dashboard is not empty, it is filtered, and the filter is invisible.

The fix is two lines and both are required

On the tag:

<script src="https://cdn.example.com/app.js" crossorigin="anonymous"></script>

And on the response, from the CDN:

Access-Control-Allow-Origin: https://www.example.com

MDN is blunt about what happens without them: with no crossorigin attribute, "access to error logging via window.onerror will be limited."

Both halves are required, and this is where it usually goes wrong. Adding crossorigin to the tag while the CDN sends no matching header does not get you better errors - it makes the request a CORS request that then fails, so the script does not load at all. A half-applied fix is worse than none, which is why this tends to get tried once, break something, and get reverted.

How to tell whether you are affected, in about a minute

Do not go looking in the dashboard for Script error., because absence there proves nothing. Cause one instead:

// In the console, on your production page:
const s = document.createElement('script');
s.src = 'https://cdn.example.com/does-not-matter.js';
s.textContent = 'throw new Error("canary")';
document.head.appendChild(s);

Better still, add a deliberate throw to a debug entry point in your real bundle, ship it behind a query flag, and read what your tracker records. If what arrives is Script error. at 0:0, every production exception from that bundle has been arriving the same way, for as long as the bundle has been on that hostname.

Why I care about this more than the fix

The interesting part is not the CORS header. It is that this is a monitoring system that fails by returning less, not by returning nothing.

An outage in your error tracker is obvious. A tracker that keeps working while silently dropping one category of error is not, because every check you would run against it comes back healthy. The errors are being reported. They are just being reported as nothing.

That shape shows up all over debugging: the browser has the information, something between you and it decides you may not have it, and what reaches you is a summary that looks like an answer. When somebody tells you the page is broken and your tools show nothing, "nothing" deserves a second question. It may mean nothing happened. It may mean the thing that happened was not allowed to tell you.

Those two look identical from where you are standing, and only one of them is good news.

Our Scheduler Never Ran for Six Days, and Every Check We Had Said It Was Fine

Vladimir Elchinov — Wed, 09 Sep 2026 12:57:41 +0000

We built a small posting scheduler: a YAML queue of things to publish, each with a time, and a runner that reads the queue and sends whatever is due. The runner keeps its own record of what it has already sent, so running it twice in a minute posts once. It has tests. It is about two hundred lines and none of them are clever.

Then we wrote the launchd job that runs it into the README, as a fenced block, with the launchctl command underneath. And moved on.

Six days later somebody noticed the posts were not happening.

The queue looked perfect

This is the part worth sitting with. Here is what the status command printed the morning we found out:

fb-2026-09-02-smoke-testing   facebook  2026-09-02 09:12  queued
x-2026-09-03-cors             x         2026-09-03 15:07  queued
fb-2026-09-04-staging         facebook  2026-09-04 09:12  queued
x-2026-09-04-connection-errors x        2026-09-04 15:07  queued

Eleven entries, all valid, all with times in the past, all saying queued. Nothing is wrong with any of them. queued is exactly what the state should say for a post that has not gone out yet, and it is also exactly what it says when nothing has ever read the file.

Those two situations are indistinguishable from inside the queue. A runner that has never executed and a runner with nothing to do produce identical output, because the evidence of the runner working is not stored anywhere the queue can see.

The plist was never installed. launchctl list | grep session-replay returned nothing, and had returned nothing since the day it was written. A documented snippet in a README reads exactly like a thing that is set up.

The check we would have run could not have caught it

We had a health check in mind, and it was the wrong one: is the queue healthy? Valid YAML, no duplicate ids, no entries pointing at articles that do not exist, no two entries at the same timestamp. All of that passed. All of it would have passed every day for six days.

The queue was healthy. The queue was never the problem. The missing piece was one level up, in a place none of the queue's own diagnostics can reach, and no amount of validating the queue harder would have found it.

The generalisable version: if the only evidence your scheduled job is running is the absence of a complaint, you have no evidence. Silence is produced by working, by having nothing to do, and by not existing, and you cannot tell which one you have.

Two more things that were quietly wrong

Once it was installed, the schedule itself had a bug we had written into the README months before anybody could hit it. It ran hourly, on minute 7. A post timed for 09:12 would not go out until 10:07 - fifty-five minutes late, silently, forever.

Worse, the X entries were written for 15:07, the same minute the runner fired. Whether the afternoon post went out on time or an hour late came down to which of the two won a race measured in milliseconds. It would have looked flaky and been almost impossible to reproduce deliberately.

Both fixed by running every ten minutes on offsets nothing else uses: 2, 12, 22, 32, 42, 52.

And the log was going to /tmp, which macOS clears on reboot. So the one artefact that would have explained a failure was configured to delete itself.

What actually fixes this

Not a better queue check. A positive trace, written by the thing you care about, checked somewhere the thing itself cannot influence.

Ours now logs every run, including the boring ones, to a path that survives a reboot:

nothing due (20 in /Users/.../social/queue.yml)
nothing due (20 in /Users/.../social/queue.yml)

That is not noise. That is the runner saying I exist and I looked, which is the exact fact the queue could not tell us. Forty of those lines and one posted entry is a healthy system. An empty file is a dead one, no matter how good the queue looks.

One last trap while wiring this up, which cost twenty minutes: the first run after loading a launchd job produces nothing for a couple of minutes. launchd spawns through xpcproxy, macOS scans the binary on first execution, and Ruby holds a redirected stdout in a buffer until the process exits. An empty log thirty seconds in reads exactly like a failure and is not one. launchctl list <label> shows the PID while it is up, and LastExitStatus once it is not. Check that, not the log, in the first two minutes.

The Extension You Vetted Is Not the One That Auto-Updates

Vladimir Elchinov — Fri, 04 Sep 2026 14:27:10 +0000

We tell people to be careful which browser extensions they install. Check the reviews, look at the permissions, prefer the ones with a name behind them. It is good advice, and it quietly assumes something that is not true: that the extension you install is the extension you keep.

It is not. Extensions auto-update, silently, in the background, from whoever controls the listing today - which is not necessarily whoever controlled it when you decided to trust it. The thing you vetted and the thing running in your browser next Tuesday can be two different programs, and nothing in the browser asks you again. The update channel, not the install, is the attack surface, and 2026 has been a long demonstration of it.

What actually happened, in one extension

In December 2025, OX Security flagged a Chrome extension called "AI Sidebar with DeepSeek, ChatGPT, Claude and more" for scraping ChatGPT and DeepSeek conversations and sending them to external domains. By then it had over 300,000 installs and a 4.6-star rating. Google pulled it in January 2026.

It came back. By August 2026 it was in the Chrome Web Store again, and Netskope Threat Labs caught a new version, 1.7.3.0, arriving through Google's own CDN between 20 and 31 July. The new payload was not stealing chats this time; it was monetizing the user. As Netskope described it, when Chrome reports that the extension has updated, a service worker opens an affiliate link in a foreground tab, routed through a URL shortener to an AI video platform. It went further: it exploited a Chrome quirk where the uninstall URL can be overwritten, so the extension earned an affiliate commission even as you removed it. It got paid on the way out.

Nobody who had this installed did anything wrong. They installed a popular, well-reviewed tool, and an update turned it into something else while they were not looking. That is the whole problem in one story.

Why the update is the soft spot

An extension is not a static download. It is a listing with an owner, and two things about that owner change over time in ways the store does not surface to you.

Ownership transfers. An extension with a real userbase is an asset, and assets get sold. A developer who built something useful, got tired of maintaining it, and sold the listing to a buyer they never met has just transferred your trust to a stranger, and you will never see the transaction. Security firm Socket documented a wave of this in 2026: extensions acquired from their original creators and then, via ordinary automatic updates, injected with code to steal credentials and cryptocurrency. The users had vetted the original authors. The original authors were gone.

Updates ship without re-review of the thing you agreed to. You granted permissions once, to a version of the code you never read, and every version after it inherits those permissions. An extension with "read and change all your data on all websites" - a permission a great many legitimate extensions genuinely need - does not have to ask again to start doing something new with it. The consent was for the permission, not for any particular use of it, and an update is a new use.

Manifest V3, which was supposed to be the big security reset, does not close this. It reworked how extensions run background code and it made some classes of remote code harder, but a service worker opening an affiliate tab on update is perfectly ordinary MV3, and so is exfiltrating data an extension is already permitted to read. MV3 changed the plumbing, not the trust model.

What this means if you use extensions

There is no browser setting that fixes a supply-chain problem, so the defenses are all about reducing exposure rather than detecting the bad update, which you cannot reliably do.

Run fewer of them. Every extension is a listing that can change hands, and the set you run is both your attack surface and, incidentally, a fingerprint a page can read. Uninstall the ones you stopped using; a dormant extension still updates.
Separate profiles by risk. Keep the extension-heavy profile away from the one you bank and work in. A profile with three extensions is a smaller target than one with thirty, and a compromise in one does not sit in the same browser as your session cookies in the other.
Watch for the tells of a sold listing: a sudden update after a long quiet period, a change of developer name or support domain, new permissions requested on update, a once-focused tool that grows features nobody asked for. None of these is proof, and all of them are worth a second look before you keep it.

What it means if you build them

The uncomfortable half: the trust your users place in you is transferable, and the store makes it easy to transfer. If you sell a listing, you are selling their trust to whoever buys it, and they will not be told. That is worth a moment's thought before the sale, and an honest note to your users is worth more than the extra few percent a buyer will pay for a silent handover.

And if you are shipping updates: the permissions you were granted are a loan, not a licence. Every update is a chance to quietly widen what you do with data you were trusted to touch for one narrow reason. The users cannot see the diff. That asymmetry is exactly what the bad actors are exploiting, and it is the reason the whole category is under suspicion it did not used to be.

Chrome Web Store enforcement did tighten in 2026 - stricter data-collection rules, closer review of whether an extension's privacy disclosures match its actual behavior, faster removals. It helps at the edges. But review happens at submission, and the attack happens at update, from an owner who looks legitimate because, until recently, they were. The gap between "I vetted this" and "this is what is running" is structural, and closing it is mostly on the two groups least inclined to think about it: the users who install and forget, and the authors who ship and move on.

If you write extensions, the kindest thing you can do for the people who trusted you is to keep deserving it on every update - and, if you ever stop, to tell them rather than sell them.

A Web Page Can Tell Which Extensions You Have Installed. Here Is How.

Vladimir Elchinov — Tue, 01 Sep 2026 15:47:33 +0000

Open a page and it can start guessing which browser extensions you run before you click a thing. Not "extensions in general" - which ones. Your password manager, your ad blocker, the wallet, the internal tool your employer ships, the accessibility extension you depend on. The page never asks and you never see it happen.

This is not a bug in Chrome. It is the sum of a few features working exactly as designed, and the people best placed to close it are extension authors who mostly do not know they left it open. I maintain an extension and a library that talks to it, so I have spent real time on the detectable side of this. Here is how a page does it, what the answer is worth to whoever is asking, and what actually stops it.

Technique one: ask the extension directly

Some extensions accept messages from web pages on purpose - our own does, so a customer's "report a bug" button can tell whether the extension is there. The API is chrome.runtime.sendMessage:

chrome.runtime.sendMessage(EXTENSION_ID, { type: 'ping' }, (reply) => {
  if (reply) {
    // it is installed, and it answered
  }
});

For a page to be allowed to send that message, the extension has to list the page's origin in its manifest, under externally_connectable. Authors who want their extension to work with any site reach for the wildcard:

"externally_connectable": { "matches": ["<all_urls>"] }

And that one line is the door. <all_urls> does not mean "my customers' sites". It means every site on the internet may now open a channel to this extension - which means every site may ping it and learn whether you have it. The convenience the author wanted for their own pages, they handed to everybody's.

This technique is narrow, because it only finds extensions that chose to talk to pages. The next one is not narrow.

Technique two: knock on the extension's own files

Extensions ship assets - icons, injected stylesheets, images. Any asset marked web-accessible is reachable at a fixed URL built from the extension's id:

chrome-extension://<extension-id>/icon-128.png

Fixed. Which means a page does not have to be given permission to look. It just tries to load the file and watches what happens:

function hasExtension(id, path) {
  return new Promise((resolve) => {
    const img = new Image();
    img.onload = () => resolve(true);
    img.onerror = () => resolve(false);
    img.src = `chrome-extension://${id}/${path}`;
  });
}

onload fires, the extension is installed. onerror, it is not. No message, no cooperation, nothing the extension author has to have agreed to beyond publishing a web-accessible file - which almost all of them do. Extension ids are public and stable; you read them off the store. So a page carries a list of ids and the resource path each one exposes, loops over it, and comes out the other side with an inventory. This is the workhorse, and it is old - security researchers demonstrated it at scale years ago and it still works today.

Technique three: do not look for the extension, look for its fingerprints

The two above need the extension's id. This one does not, and it catches the extensions that never talk to pages and ship no web-accessible files.

An extension that changes a page leaves marks, and a page can bait them out. An ad blocker hides elements that look like ads, so plant one and see if it vanishes:

const bait = document.createElement('div');
bait.className = 'ad-banner ad-slot sponsored';
bait.style.cssText = 'position:absolute;height:10px;left:-9999px';
document.body.appendChild(bait);

requestAnimationFrame(() => {
  const blocked = bait.offsetHeight === 0 ||
                  getComputedStyle(bait).display === 'none';
  // blocked === true means something is hiding ad-like elements
});

A password manager injects an icon into password fields, so put a hidden password input on the page and watch for the DOM to change around it. You do not learn which ad blocker or which password manager, but you learn the visitor runs one - and often that is the fact that mattered.

So a page has a list of your extensions. What is that worth?

This is the part that turns a curiosity into a reason to care.

It is a near-unique fingerprint. The particular set of extensions you run is close to an identifier, and unlike a cookie you cannot clear it. It rides along with every other fingerprint signal and sharpens all of them.

It deanonymises you by inference. This is the sharp end. Extensions are not neutral - many of them say something about the person:

an internal SSO or admin extension that only one company ships → the visitor works there
a specific screen reader or accessibility extension → an accessibility need, which is about as sensitive as attributes get
a particular crypto wallet → the visitor holds crypto, which is exactly what a phishing page wants to know before it decides whether you are worth the effort
a competitor's extension → this landing page can quietly greet their customer differently from everybody else

It happens before you do anything. Every technique above runs on page load. By the time you have read the headline, the page has tailored itself - or decided what you are - off a signal you did not know you were sending.

None of this requires a breach or a trick. It is the platform behaving as documented, aimed at a question you were never asked whether you wanted answered.

What actually stops it

The good news is that the fixes exist and most of them belong to the extension author, not to you.

For technique two, Manifest V3 gave authors the answer: use_dynamic_url.

"web_accessible_resources": [{
  "resources": ["icon-128.png"],
  "matches": ["https://your-real-site.com/*"],
  "use_dynamic_url": true
}]

Two things there. use_dynamic_url makes the resource's URL a per-session random token instead of the fixed path, so the <img> probe has nothing stable to request. And matches narrows who may load the resource at all, instead of leaving it open to every origin. Ship a web- accessible file with neither and you are the reason technique two still works.

For technique one, do not write <all_urls>. List the origins that genuinely need to talk to your extension. If that list cannot be known ahead of time - it is our exact case, a library any customer can install - then do not use externally_connectable at all. We do detection the other way around: the extension injects a content script that listens for a CustomEvent the page dispatches, and answers with another. A page that has not deliberately loaded our library and fired the event learns nothing, because the channel only carries a reply to a page that asked. The page can only find the extension by cooperating with it, which is the opposite of a silent probe.

For technique three there is no clean fix, because the detection is of the extension's effect, not the extension. Injecting into the page is the whole job. The best an author can do is be less trivially baitable - scope styles tightly, avoid marker classes and ids a page can guess. It is mitigation, not a cure.

And as a person who just wants to be probed less: the extensions you install are a fingerprint, so run fewer of them, and keep the ones that matter in a separate browser profile from the one you do sensitive things in. A profile with three extensions is a much larger crowd to hide in than one with thirty.

The theme under all of it is the one that runs through most browser-privacy problems: a feature added for a good reason, used at its most convenient setting, adds up to a capability nobody decided to grant. <all_urls> and a fixed resource URL are each perfectly reasonable in isolation. Together they mean the page you just opened knows things about you that you would not have told it.

If you write extensions, the ten minutes it takes to set use_dynamic_url and a real matches list is the cheapest privacy win you will ship this year. Your users cannot do it for you, and they will never know you did.