DEV Community: Session Replay

Your Number Input Reads Empty, and the User Did Type Something

Vladimir Elchinov — Fri, 30 Oct 2026 13:59:16 +0000

The support ticket is short and sounds impossible. The form says the price is required. There is a price in the box. They can see it, they photographed it, and your validation still refuses to move on.

Both halves are true. The box contains 1,5 and your code is reading the empty string.

The rule that erases it

The HTML Standard defines a value sanitization algorithm for <input type="number">, and it is one sentence:

If the value of the element is not a valid floating-point number, then set it to the empty string instead.

Not "leave it alone". Not "keep the text and let the author decide". Set it to the empty string.

And a valid floating-point number is defined precisely, as optional sign, digits, and:

A single U+002E FULL STOP character (.)

A full stop. The grammar has no comma in it anywhere, in any locale, under any language setting. Roughly half the planet writes decimals with a comma, and this is one of the places where that is not a formatting preference but an invalid character.

The part that actually costs you

Here is the bit worth the ten minutes, and it is not the comma.

When a value fails that check, input.value is "". The same "" you get from a field nobody has touched. The two situations are now indistinguishable to every piece of code you own:

if (!priceInput.value) {
  // "You must enter a price."
  // Was the field blank, or did we just throw away what they typed?
}

Your required-field check cannot tell them apart. Neither can your form analytics, which will record an abandoned field. Neither can the log line you add while debugging it, because you will log value and see an empty string and believe the user.

That is why this report arrives as a contradiction. The user says there is a number in the field. Your instrumentation says the field is empty. Nobody is lying and nobody can see the discrepancy from where they are standing.

The one field that knows

The browser does keep the distinction. It is just somewhere nobody looks:

if (priceInput.validity.badInput) {
  // They typed something. It could not be converted.
} else if (!priceInput.value) {
  // Genuinely empty.
}

MDN defines badInput as indicating "if the user has provided input that the browser is unable to convert", and gives this exact case as its example: "if you have a number input element whose content is a string".

Two branches instead of one, and the error message can stop being a lie. "Use a full stop for decimals" is a message somebody can act on. "This field is required" is a message that makes them doubt their own eyes.

Worth knowing: the sibling behaves differently

type="range" has the same kind of sanitization rule and a different ending. Where number sets the value to the empty string, range sets it to a default instead.

So the same class of mistake is loud in one control and silent in the other. On a range, bad input quietly becomes a legitimate-looking number that the user never chose, and nothing anywhere reports a problem. Worth remembering if you are tempted to treat these two as variations on one input.

Why you will never see it

This failure is selected by the user's keyboard and locale rather than by their browser, their operating system or their network. It has no version number attached to it.

If your machine and your test data produce a full stop, the field works perfectly for you forever. There is no flag to toggle, no device lab that surfaces it, and no field in any bug report template that asks which decimal separator somebody's culture uses. The closest you will get is noticing that the complaints cluster in one country, which takes a surprisingly long time when each one arrives individually and sounds like user error.

The whole thing is recoverable from one boolean the browser was willing to tell you all along. It just never came up, because the value looked empty and empty looked like an answer.

The Button Moved Before Your Finger Landed, and Your Click Handler Is Innocent

Vladimir Elchinov — Thu, 29 Oct 2026 13:58:37 +0000

The ticket says: "I pressed Cancel and it deleted my draft."

You open the code. The Cancel handler cancels. The Delete handler deletes. Nothing is crossed, nothing is mislabelled, and the click that arrived went to Delete because Delete was genuinely under that finger at the moment it landed. Both of you are describing the same event correctly and neither description contains the cause.

Something above those buttons changed size about eighty milliseconds earlier.

The browser already has a defence, and you have probably never configured it

There is a feature aimed squarely at this class of problem. MDN:

Scroll anchoring behavior adjusts scroll position to minimize content shifts.

And the line that explains why you have never thought about it:

Scroll anchoring behavior is enabled by default in any browser that supports it.

It works silently, so it is invisible until it is absent. Two things about it are worth holding.

It is one line to switch off. overflow-anchor: none opts an element out: in MDN's words, that element "won't be selected as a potential anchor". That is a reasonable line to write when you are fighting a different scroll bug, and a very easy line to leave behind. Nothing warns you that a protection is now off, because nothing announced it was on.

Its job is the scroll position. Read the definition again: it adjusts scroll position to minimise shifts. That keeps what somebody is reading where they are reading it. It is not, and does not claim to be, a promise that the element under a pointer at one instant is the same element 80ms later.

The measurement has a blind spot exactly where it hurts

Here is the part that costs you something.

Layout shifts are reported through LayoutShift entries, and each one carries hadRecentInput. MDN defines it precisely:

returns true if lastInputTime is less than 500 milliseconds in the past

Shifts flagged that way are normally dropped, and the reasoning is sound as far as it goes:

Layout shifts are only a problem if the user is not expecting them, so layout shifts that are the result of user interactions (such as a user expanding a UI element) are often not considered in layout shift metrics.

That is correct for a user opening an accordion. But notice what the rule is made of: a 500 millisecond window bracketing user input. A mis-tap is, by definition, an event where a shift and an interaction happened within milliseconds of each other. The filter is not wrong, it is simply blind in the one window where this particular failure lives.

So a dashboard can be green while this happens, and the green is not a lie. It is an answer to a different question.

Record the shifts you are told to ignore

The fix is not to distrust the metric. It is to keep a second, unfiltered copy for debugging:

new PerformanceObserver((list) => {
  for (const shift of list.getEntries()) {
    // Deliberately NOT filtering on hadRecentInput: those are the interesting ones here.
    recent.push({
      at: Math.round(shift.startTime),
      value: shift.value,
      nearInput: shift.hadRecentInput
    });
  }
}).observe({ type: 'layout-shift', buffered: true });

Keep the last handful in memory and attach them to whatever you already send when something goes wrong. A click log that says deleteDraft at 12840ms is ambiguous. The same log beside a shift of 0.03 at 12795ms is not ambiguous at all: something moved 45 milliseconds before the click, and you now have a timestamp to go and look at.

Why the report will never contain this

Nobody writes "the layout moved as I was tapping". They do not perceive it as movement. They perceive it as having pressed the wrong thing, or as the application doing something they did not ask for, and the report is written in those terms because that is the honest account of their experience.

The information that would settle it is the position of two elements during a window of about a tenth of a second, on their device, at their connection speed, with whatever loaded late that day. It is not in your logs, it is not in their description, and by the time anybody looks the page has settled into the layout you would have predicted.

Which is the general shape: the evidence that decides this bug has a shorter half-life than the time it takes anybody to notice there is a bug.

Your Error Tracker Shows Zero Crashes Because It Lives Inside the Thing That Crashed

Vladimir Elchinov — Wed, 28 Oct 2026 13:59:03 +0000

Open your error dashboard and filter for renderer crashes. You will find none. That is not because your pages do not crash.

Chrome shipped 52 security fixes yesterday, four of them critical, and the classes read: memory corruption, use after free, improper input validation. Those do not throw an exception. They take the process down. The tab goes grey, or it reloads itself, or it simply stops being a page.

The structural problem, not a missing feature

Everything you installed to tell you about a failure runs in the page. When the page is the casualty, so is the reporter. window.onerror did not stay quiet; it was never called, because nothing was left running to call it.

MDN says this outright about the browser's own crash report, which cannot be picked up by a ReportingObserver for the plainest possible reason:

the reports are only generated when the browser crashes, at which point the observer code isn't available to run.

So there is no listener for this. Not a try/catch, not an unhandledrejection handler, not a ReportingObserver. The event you most want is the one your page cannot be awake for.

What works is a header, not a script

The only route is the browser reporting it afterwards, on its own, out of band. That is one response header:

Reporting-Endpoints: crash-reporting="https://example.com/reports"

No bundle change, nothing to initialise, nothing that can fail to load. That is the point: it has to work when your JavaScript does not exist.

Three things that will make you think it is broken

This is the part worth knowing before you wire it up, because each one looks like failure.

It is slow on purpose. Chrome's documentation: "Reports are delivered out-of-band from your site", and reports are "sent with a delay" of up to a minute so the browser can batch them. The browser "captures, queues, and sends them automatically at a suitable time". Crash a tab, watch your endpoint, see nothing, conclude it does not work: that is the obvious mistake and you will make it within the first five minutes.

A non-secure endpoint is dropped in silence. MDN: "Non-secure endpoints are ignored." No console warning, because there is no console to warn in.

Nothing in your code proves it is on. It is a header, so it does not appear in your bundle, your dependency list or your init path. The only way to know it is live is to look at a response, which is also the only way to notice that a proxy or a CDN stripped it.

What actually arrives

A POST with Content-Type: application/reports+json. Each report carries age in milliseconds since it was generated, plus type, url, user_agent, and a body whose shape depends on the type.

age is the field that earns its place. The report arrives late by design, so the arrival time is not the incident time, and age is what converts one into the other. Log the arrival and you will put the crash a minute after the thing that caused it.

For a crash, the field to read is reason. MDN documents two values:

oom: the page ran out of memory.
unresponsive: the page was killed due to being unresponsive.

Why that one field is the whole diagnosis

Those are different bugs with different fixes. One is a leak or an allocation you did not bound. The other is work on the main thread that never yielded.

They are also the exact distinction the person in front of the problem cannot make for you. "It crashed" and "it froze so I closed it" are the same sentence to them, chosen by mood rather than by mechanism, and the report arrives with that choice already baked in. reason is measured instead of typed, which is why it is worth more than the paragraph describing it.

The thing to do, and the thing to ask

Set the header. It costs one line and it covers the case your in-page instrumentation is structurally unable to reach.

Then, when somebody says a tab died, ask one question before anything else: did the whole tab go, or did the page stop responding first? You are asking them to separate oom from unresponsive without using either word, and it splits the problem in half before you have started looking.

A zero on that dashboard was never a fact about your software. It was a fact about where you put the instrument.

Browser Zoom Changes the Size of a CSS Pixel, and Your Bug Report Cannot See It

Vladimir Elchinov — Tue, 27 Oct 2026 14:03:59 +0000

A report arrives with a screenshot. The sidebar has collapsed into the narrow layout, on a desktop, where it should never collapse. You ask for their screen size, because that is what the layout depends on. They say 1920 by 1080, which is true.

You open the page at 1920 by 1080. The sidebar is fine.

Zoom is not magnification

The model most of us carry is that browser zoom works like a magnifying glass held over a finished page: same layout, bigger pixels. It does not. It changes the unit the layout is written in.

MDN, on devicePixelRatio:

When a page is zoomed in (made larger), the size of a CSS pixel increases, and so the devicePixelRatio value increases.

The size of a CSS pixel increases, so everything measured in CSS pixels has fewer of them to work with. A window 1920 device pixels wide at 125% zoom hands your stylesheet a viewport of about 1536 CSS pixels, and your (max-width: 1600px) rule is not misfiring when it collapses the sidebar. It is correct. The viewport genuinely is narrower than 1600 of the unit the rule is written in.

So there is no bug in the layout and no error in the report. There are two different widths, and the only one either of you mentioned is the one that decides nothing.

They will not tell you, because they do not know

This would be a harmless difference if zoom were something people did and then undid. From Chrome's own help:

The chosen zoom level will be saved for this specific site and won't affect other sites.

Saved, for your site specifically. Somebody held ctrl and turned a scroll wheel eight months ago, or zoomed in once to read a small label, and your site has rendered at 110% for them ever since. It survives a restart, which is why "I restarted the browser and it is still broken" is a perfectly consistent thing for them to report.

It is also not a state they can see, so asking whether they are zoomed in gets an honest no.

And it is worth remembering why many people are zoomed in: because the text is too small for them to read at 100%. "Press ctrl+0" is not a fix for that person. It is a request that they go back to using your site uncomfortably.

The number you would reach for cannot answer it

Having learned that devicePixelRatio moves with zoom, the obvious next step is to log it. It will not tell you what you want to know.

MDN defines it as "the ratio of the resolution in physical pixels to the resolution in CSS pixels for the current display device". The display's own density and the page's zoom both change that ratio, so a single reading of 1.5 is either a high density screen at 100% or an ordinary one at 150%, and nothing in the number separates the two.

The other scaling number does not close the gap. visualViewport.scale returns "the pinch-zoom scaling factor applied to the visual viewport", and MDN is explicit that pinch-zooming "does not affect devicePixelRatio, because this magnifies the page without changing the size of a CSS pixel". One number carries desktop zoom blended with display density. The other carries pinch-zoom alone. Neither of them reports a zoom level, and no standard property does.

People do estimate it anyway, usually by comparing one window measurement against another. That is an inference built from two numbers that each move for their own reasons, and a bug report wants a reading.

Record the decision, not the zoom

The move that works is to stop trying to recover the zoom level and record what the layout actually decided:

const layout = {
  // the width the rules saw, in the unit the rules are written in
  viewport: [window.innerWidth, window.innerHeight],
  dpr: window.devicePixelRatio,
  pinch: window.visualViewport?.scale,
  // the branches, recorded rather than reconstructed later
  narrow: window.matchMedia('(max-width: 1600px)').matches,
  coarse: window.matchMedia('(pointer: coarse)').matches
};

The matchMedia lines record the decision itself, rather than leaving you to work backwards to it from a width. And if you keep only one field, keep innerWidth: a reporter who says 1920 and a page that says 1536 have told you, between them, everything you need to reproduce it, and neither of them had to understand why.

The ceiling on asking

Nearly every field in a bug report template is something the person can look up: browser, operating system, screen size, what they clicked. Zoom is an input to your layout that neither end can look up, because they do not know it and the page cannot read it back. The facts a template collects and the facts that decide a layout bug are not the same set, and the gap does not close by adding another question to the form.

In a Background Tab, setInterval(fn, 1000) Runs Once a Minute

Vladimir Elchinov — Mon, 26 Oct 2026 13:58:23 +0000

Somebody leaves your dashboard open in a background tab, comes back after lunch, and the number on screen is twenty minutes stale. Or the countdown is wrong. Or they were never logged out when they should have been.

Nothing threw. Nothing appeared in the console. Your timer simply stopped running at the rate you asked for, an hour ago, and never told anybody.

The rule, in Chrome's own words

Chrome applies what it calls intensive throttling when all four of these are true:

"The page has been hidden for more than 5 minutes."
"The chain count is 5 or greater."
"The page has been silent for at least 30 seconds."
"WebRTC is not in use."

And then the consequence, stated plainly: "the browser will check timers in this group once per minute."

Once per minute. Not "a bit later than you asked". Not jitter. Your one-second interval becomes a sixty-second one, and the only thing that changed is that the user looked at a different tab.

Your code is "chained" whether you meant it or not

The chain count is the condition people assume will save them, and it will not. Chrome defines it like this:

If you call setTimeout in the same task as a setTimeout callback, the second invocation is "chained". With setInterval, each iteration is part of the chain.

Read that second sentence carefully. Every iteration of a setInterval adds to the chain, so a plain setInterval crosses the threshold of five on its fifth tick and stays there forever.

And the other common shape is chained too: the poll that schedules the next poll at the end of its own callback. That is setTimeout called in the same task as a setTimeout callback, which is the definition.

Between those two, most timer code anybody writes is chained by construction.

The bug this actually causes

The slowdown is the obvious half. The subtle half is that code which counts ticks silently produces wrong answers, rather than slow ones:

// Wrong in a background tab: it is counting ticks, not time.
let elapsed = 0
setInterval(() => {
  elapsed += 1000
  if (elapsed > SESSION_LIMIT) expireSession()
}, 1000)

After five minutes hidden, that runs once a minute, so elapsed advances by one second per minute of real time. A thirty-minute session limit now expires after thirty hours of wall clock. The user is not logged out, and your security control quietly stopped being one.

// Right: it reads the clock, so a late tick is still correct.
const start = Date.now()
setInterval(() => {
  if (Date.now() - start > SESSION_LIMIT) expireSession()
}, 1000)

Both versions run once a minute when hidden. Only the second is still right when it runs. That is the whole fix, and it is the general rule for anything timer-driven: never accumulate, always compare against the clock.

Why you will never see it yourself

Your tab is focused. A visible page gets minimal throttling, which is to say none at all, so the entire behaviour is invisible from the seat you develop in.

Two of the four conditions make it worse, because they create people who genuinely cannot reproduce it. A page that "has made noises in the past 30 seconds" is exempt, and so is one using WebRTC. So a video-call app is fine while a dashboard is not, and the colleague who happens to have a sound playing in that tab will tell you it works for them.

What reaches you instead

The report says the timer was wrong, or the page was stale, or it did not log them out. All three are true, none of them is reproducible on your machine, and the fact that would explain it, that the tab sat in the background for more than five minutes, is not something anybody thinks to mention. It is not a detail about your software. It is a detail about what else they had open.

Your Autoplay Works Because Chrome Has Learned to Trust You

Vladimir Elchinov — Fri, 23 Oct 2026 12:58:29 +0000

Your video autoplays every single time you load the page. It does not autoplay for somebody arriving for the first time, and there is no bug in your code.

Chrome has been keeping a score on you, per site, and you have been raising it all week.

The score is real and you can read it

Chrome's autoplay documentation states the rule plainly. Autoplay with sound is allowed if "The user has interacted with the domain (click, tap, etc.)" or, on desktop, if "the user's Media Engagement Index threshold has been crossed, meaning the user has previously played video with sound."

The Media Engagement Index "measures an individual's propensity to consume media on a site", and Chrome calculates it as "a ratio of visits to significant media playback events per origin."

A playback counts as significant only when all of these hold:

"Consumption of the media (audio/video) must be greater than seven seconds."
"Audio must be present and unmuted."
"The tab with the video is active."
"Size of the video (in px) must be greater than 200x140."

Read that list again as a description of what you do all day when you are working on a video feature. You load the page, you unmute it to check the sound, you watch more than seven seconds of it to see whether it stutters, you do it in the tab you are looking at, at a normal size.

Every one of those is a significant playback event for your own origin.

Which makes this worse than ordinary unrepresentativeness

You are not merely an unrepresentative tester for this feature. You are becoming less representative with every test. The more carefully you check that autoplay works, the more confident Chrome becomes that you personally like watching video on this domain, and the more reliably it will let the video play for you and nobody else.

The useful part is that none of this is hidden. Open about://media-engagement and Chrome lists the score it is keeping, per origin, for your profile. Find your own site in that list. If the score is high, you have not actually tested autoplay in months, whatever your last few page loads suggested.

Meanwhile the failure is silent by default

Here is the code almost everybody writes:

// Looks fine. Fails silently for a first-time visitor.
videoEl.play()

Chrome is explicit about what happens next: "calls to play() without a user gesture will reject the promise with a NotAllowedError DOMException." And it gives the instruction most code ignores: "You should always look at the Promise returned by the play function to see if it was rejected."

A bare videoEl.play() throws that rejection away. Nothing appears in the console, nothing reaches your error tracker, and the video simply sits there showing its first frame. From the user's side, the page is broken in a way they have no words for.

videoEl.play().catch((err) => {
  if (err.name !== 'NotAllowedError') throw err
  // Chrome declined. Fall back to something that is always permitted.
  videoEl.muted = true
  videoEl.play()
  showUnmuteButton()
})

That fallback works because of one more line in the same documentation: "Muted autoplay is always allowed." Start muted, give the user a control, and the experience stops depending on what the browser has decided about them.

Why the report will not say any of this

The bug report says the video does not play. It cannot say more than that, because nothing told the user anything: no error dialog, no console message they would ever see, no indication that a decision was made about them at all.

And you cannot reproduce it, by construction. Your profile has a high engagement score for your own origin and theirs has none. A fresh profile or a guest window will show you the failure in ten seconds; your ordinary browser, the one you have been working in, never will. That is the whole gap, and it widens every day you spend on the feature.

Your Tab Was Discarded, and Nothing in Your Code Was Told

Vladimir Elchinov — Thu, 22 Oct 2026 12:59:06 +0000

A user leaves a tab open overnight with a half-filled form in it. In the morning they click back to it and the form is empty. The tab looked exactly as they left it: right title, right favicon, sitting where it always sat.

They are not misremembering, and nothing on your page failed. Chrome threw the page away and told nobody.

What actually happened

Chrome's own description of Memory Saver: "When Memory Saver mode is enabled, Chrome will proactively discard tabs that have been unused in the background for some time." And then, "If the user revisits that tab, the page will be reloaded automatically."

The sentence that explains why the user cannot tell you any of this is the next one: "When a tab is discarded, its title and favicon still appear in the tab strip but the page itself is gone."

So there is no cue. A discarded tab is visually identical to a live one. The person clicking it has no reason to think anything happened between last night and this morning, because from where they sit, nothing did.

Why nothing in your code noticed either

This is the part worth knowing, because the instinct is to reach for a save-on-exit handler and it will not help.

The page lifecycle documentation defines the state plainly: "A page is in the discarded state when it is unloaded by the browser in order to conserve resources." Entering it fires no events, and once there, "No tasks, event callbacks, or JavaScript of any kind can run in this state."

Not beforeunload. Not pagehide. Not unload. Your handler does not run late, it does not run at all, because there is no unload from the page's point of view. There is a page, and then there is no page.

The last callback you get is freeze, which fires when the tab goes from hidden to frozen, and even that comes with a caveat: "freezable tasks in the page's task queues are suspended until the page is unfrozen". For a tab that is subsequently discarded, unfrozen never arrives, so anything you queued at freeze time and did not finish synchronously is gone with everything else.

What it costs you, which is more than one empty form

Measure this and it does not look like a browser behaviour at all. A discard followed by a return is a fresh page load, so in your analytics one person becomes two sessions, with an abandoned form in the first and a cold start in the second. The funnel reports a bounce and a new arrival. The truth is one user who never left.

That is the part that quietly skews numbers nobody is auditing: not a lost form, but a session count that includes an event the user did not cause.

The one fact that settles it

There is a flag for exactly this. Chrome again: "It is possible to detect that a tab was discarded after a user returns to it and the page is reloaded. In these situations the document.wasDiscarded property will be true."

// On load: was this page here before, and thrown away?
if (document.wasDiscarded) {
  restoreDraft(sessionStorage.getItem('draft'))
  analytics.track('page_load', { cause: 'tab_discard' })
}

// Last chance to write anything down.
document.addEventListener('freeze', () => {
  sessionStorage.setItem('draft', currentDraft())
}, { capture: true })

sessionStorage is the right place, and the reason is worth a sentence. A discard destroys the page, not the tab: the tab keeps its slot, its title and its favicon, and sessionStorage is scoped to that tab rather than to the document in it. So it is still there on the other side. This is the one case where the per-tab store outlives the thing you would expect to outlive it.

Why this reaches you as an unreproducible report

Your own tab is focused. Focused tabs do not get discarded, so you will not see this while you are working on the page, and you will not see it in the ten minutes you spend trying to repeat it.

Meanwhile the report says "I came back and my work was gone", which sounds like a bug in your form. There is no error, no console output, nothing in your error tracker, and nothing the reporter can tell you, because the browser did not tell them either. The single piece of evidence that separates "your save is broken" from "the browser discarded the tab" is a boolean that was true for one moment in somebody else's browser, and unless something was reading it then, it is not recoverable afterwards.

`localStorage.clear()` Tells Your Other Tabs Nothing They Are Listening For

Vladimir Elchinov — Wed, 21 Oct 2026 13:01:54 +0000

A user clicks log out, switches to their other tab, and is still signed in. You cannot reproduce it, because you test with one tab open, and with one tab open it works perfectly.

Two pieces of browser behaviour meet to produce this, and each is reasonable on its own.

The event you are listening for deliberately skips you

The storage event is how two tabs on the same origin find out about each other. MDN is exact about who receives it: it "fires when another document that shares the same storage area (either localStorage or sessionStorage) as the current window updates that storage area", and then flatly, "The event is not fired on the window that made the change."

That is the right design, and it is usually invisible. The tab where somebody clicked log out does not need an event, because it already knows. So the handler gets written, tested in a single tab, and the local half works. Whatever is broken about the cross-tab half has no symptom on your machine.

The event the other tabs get has no key on it

This is the part that costs the afternoon. Most handlers are keyed on the thing they care about:

window.addEventListener('storage', (e) => {
  if (e.key === 'auth.token' && e.newValue === null) {
    store.clearSession()
    location.assign('/login')
  }
})

That is correct if your logout path calls localStorage.removeItem('auth.token'). Plenty of logout paths call localStorage.clear() instead, which is the more cautious instinct when a session ends: take everything, leave nothing behind.

The HTML specification says exactly what clear() broadcasts. Its step is to "Broadcast this with null, null, and null." One event, not one per key, and key, oldValue and newValue are all null. There is nothing in it that names what was removed.

So e.key === 'auth.token' is false. The handler returns. The other tab keeps running with the token it read into memory at load, and keeps making authenticated requests with it until something forces a reload. Nothing throws. Nothing reaches your error tracker. The tab is just still logged in, which is the one outcome the feature existed to prevent.

Treating a null key as "all of it went" is the whole fix:

window.addEventListener('storage', (e) => {
  const cleared = e.key === null
  const tokenRemoved = e.key === 'auth.token' && e.newValue === null
  if (cleared || tokenRemoved) {
    store.clearSession()
    location.assign('/login')
  }
})

Worth knowing even if you never call clear() yourself: a third-party script on your page can, and your handler will not notice that either.

Why nobody reports this usefully

The reporter's description is of one tab. The state that explains the bug is in the other one, and they closed it before writing to you, because it did not look relevant. It was open, it was signed in, and that was the normal state of their afternoon.

So you get "logging out does not work", which is false in the sense that matters to you, since it plainly works. Everything a reporter can tell you about the tab in front of them is consistent with the feature being fine. Nothing about the way the problem presents itself suggests that the number of tabs is the variable, which is why the answer usually arrives by accident, weeks later, from somebody who happened to have two windows open while watching a network panel.

sessionStorage is not the way out

The obvious reaction is to put the token somewhere per-tab instead. That does solve the cross-tab disagreement, and it introduces a subtler question about where a new tab's session comes from.

MDN: "If the page has an opener, the sessionStorage is initially a copy of the opener's sessionStorage object. However, they are still separate and changes to one do not affect the other." The specification's version is that after creating a new auxiliary browsing context, "the session storage is copied over".

Whether a new tab starts with a copy of the old one's data therefore depends on how it was opened. window.open(url) with default features sets an opener, so the copy happens. A plain <a target="_blank"> does not, because target="_blank" now "implicitly provides the same rel behavior as setting rel="noopener"", and with no opener there is no auxiliary context to copy from. Two links that look identical in the markup, two different starting states.

None of this is obscure, and all of it is invisible from a single tab. That is the part worth carrying: the variable that explains the bug was never in the report, because the reporter had no reason to think a second tab was part of the story.

Every Origin Your Page Talks To, and the Four Traps in Listing Them

Vladimir Elchinov — Tue, 20 Oct 2026 12:58:16 +0000

Safari 27 now blocks a category of third-party domain outright, at the network level, on by default. Whatever you think of that, it leaves every team with the same question: do we have one of those on our pages?

Most teams cannot answer it, and not because they are careless. These things arrive through a tag manager or a marketing vendor, which means the thing that added them is configuration rather than code. Reading your repository will not tell you, and the answer can change without a deploy.

So here is how to actually get the list, and the four things that quietly stop you.

The cheap version, and what it misses

The network panel answers it for one page load, on your machine, on the path you happened to take, with your extensions and your cookie state. That is genuinely useful and it is not an audit. The request that only fires for logged-in users on the checkout page is not in it.

A better local version is Resource Timing, because it enumerates what the page actually fetched rather than what you watched it fetch:

performance.getEntriesByType('resource')
  .map(e => new URL(e.name).origin)
  .filter((o, i, a) => a.indexOf(o) === i && o !== location.origin)
  .sort()

MDN is explicit that this covers XMLHttpRequest, images and scripts alike, and that cross-origin resources do appear in the list. Many of their timing fields are restricted to 0 without a Timing-Allow-Origin header, but you are reading name, not timings, so that restriction does not cost you anything here.

Trap one: the buffer is small. MDN: "By default only 250 resource timing entries are buffered." A heavy page passes that without trying, and the entries you lose are silent. If you want all of them, observe instead of sampling:

new PerformanceObserver(list => {
  for (const e of list.getEntries()) console.log(new URL(e.name).origin);
}).observe({ type: 'resource', buffered: true });

The version that covers pages you never visit

Everything above runs where you are standing, which is the thing that makes the original problem hard. The answer that covers every page and every real visitor is a response header, and it blocks nothing.

Content-Security-Policy-Report-Only "helps to monitor Content Security Policy (CSP) violations and their effects without enforcing the security policies", in MDN's words. So you can declare a policy you know is wrong, deliberately, and collect what breaks it without breaking anything.

Content-Security-Policy-Report-Only: connect-src 'self'; report-to csp-endpoint

That says connections should only go to your own origin, which is false, and that is the point. Every outbound connection to anywhere else is reported to you, from production, from real browsers, on pages you have never opened.

Trap two, and it is the one that wastes an afternoon. From the same page: "The CSP report-to directive must be specified for reports to be sent: if not, the operation won't have any effect." A report-only header with no reporting destination is not a quiet success. It does nothing at all, and it looks exactly like a policy nothing is violating.

Trap three: report-to is the modern directive and is not universally supported. MDN declares both in its own example, noting that report-to is preferred over the deprecated report-uri "but we declare both because report-to does not yet have full cross-browser support". If you only set the modern one you will collect reports from some browsers and conclude the others are clean.

Trap four: you cannot do this from a <meta> tag. MDN states that this header "is not supported inside a <meta> element". If your deployment makes response headers awkward, the workaround you were about to reach for is silently ignored.

Why the list is worth having before you need it

Any one of these origins can stop answering for reasons that never reach you: a browser default, an extension, an endpoint security product, a corporate proxy, a network that resolves it differently.

When that happens, the request is refused in somebody else's browser. Your server sees nothing, because there is nothing to see. Your logs are complete and useless. What arrives is a person saying that signing up did not work, with no mention of a third party, because they cannot see one either.

Having the list already is the difference between that being a mystery and being a short conversation. It takes an afternoon once, and the alternative is learning which third parties you depend on at the moment one of them disappears.

Your await Can Spend the User's Gesture Before You Use It

Vladimir Elchinov — Mon, 19 Oct 2026 12:58:25 +0000

The copy button works. You have clicked it forty times. A user says nothing happens when they click it, and sends a screenshot of a button, which is not helpful because the button looks exactly the way it looks when it works.

There is a good chance the difference between you and them is not the browser, the extension or the operating system. It is how long their network took in the middle of your click handler.

The rule you are up against

A set of browser APIs will only run if the user has recently and deliberately interacted with the page. MDN calls that state transient activation, "a window state that indicates a user has recently directly and meaningfully interacted with the window".

Two properties of it are the whole story.

It expires. MDN says transient activation "expires after a timeout (if not renewed by further interaction)", and pointedly does not say how long that timeout is. It is not a number you can code against.

It can be consumed. The same page says it "may also be consumed/deactivated after using some gated features", with Window.open() as the example. Using one gated feature can leave you without activation for the next.

The shape that fails

button.addEventListener('click', async () => {
  const res  = await fetch('/api/share-link');   // the gesture is burning here
  const data = await res.json();
  await navigator.clipboard.writeText(data.url); // may now be refused
});

That is ordinary, readable code, and it works perfectly on your machine, because fetch against a local API comes back in single-digit milliseconds and the activation is still alive when the clipboard call runs.

On a real connection that same round trip is a few hundred milliseconds. On hotel wifi or a train it is seconds. The code did not change. The gesture ran out.

So the failure is a function of latency, which is why the person who wrote it never sees it, and why "works for me" is true rather than careless.

It is a cluster, not one bug

Clipboard is the one people meet first, but MDN's list of features gated by transient activation is long and the same pattern breaks all of them. Element.requestFullScreen(). Window.open(). Navigator.share(). MediaDevices.getDisplayMedia(). HTMLInputElement.showPicker(). The file pickers, showOpenFilePicker() and friends.

If you have ever been told "the browser blocks popups", this is usually what was actually happening. The browser did not object to the popup. It objected to a popup opened with no live gesture behind it, which is a different rule with a different fix.

Why `beforeunload` is not like this

Worth knowing, because it is the thing that makes people think activation is simpler than it is.

MDN separates transient from sticky activation: "transient activation only lasts for a short while, and may in some cases be consumed (deactivated) when a protected feature is used, while sticky activation persists until the end of the session". The beforeunload event, autoplay and Navigator.vibrate() are on the sticky list.

So your unsaved-changes dialog fires reliably after any interaction at all, and your clipboard call does not, and the inconsistency is specified rather than accidental.

What to do about it

Call the gated API first, with whatever you already have, and do the slow part after.

button.addEventListener('click', async () => {
  await navigator.clipboard.writeText(buildUrlLocally());  // gesture still live
  track('copied');                                         // the slow part, after
});

Where the value genuinely has to come from the server, the fix is to stop the gesture and the request from being in the same sequence: fetch it when the component mounts, or on hover, or on pointerdown rather than click, so that by the time the user commits, there is nothing left to wait for.

And do not let the call fail silently. All of these reject rather than returning a status, so a bare await with no catch produces exactly the symptom the ticket describes: nothing happened, no error on screen, nothing in your logs.

The part that makes it expensive

The fact that decides whether this works is how long one request took on somebody else's connection at the moment they clicked.

That number is not in the bug report. It is not in your server logs either, because the request you would want to time is the one that succeeded, and the thing that failed afterwards never reached you at all. The reporter cannot supply it, because nothing they can see distinguishes a slow success from a refusal.

Which is the ordinary shape of the reports that take longest: not difficult once you know, and invisible from where you are standing.

Two Date Strings One Character Apart Land on Different Days

Vladimir Elchinov — Fri, 16 Oct 2026 12:58:48 +0000

A support ticket says the delivery date is showing a day early. You open the page. The date is correct. You check the database. Correct. You ask them to clear their cache, which does nothing, because nothing about this is cached.

They are right and you are right, and the thing standing between you is a rule in the language about when a date string means UTC and when it means wherever the reader happens to be standing.

The rule

A date-only string is parsed as UTC. The same string with a time attached is parsed as local.

That is not a quirk of one engine. It is what the specification asks for, and MDN states the two halves plainly. Of "2019-01-01" it says the string "will imply UTC time because it's date-only". Of "2019-01-01T00:00:00" it says the call "will be set to 2019-01-01 at 00:00:00 in the local timezone of the system, because it has both date and time".

So these two are not the same instant:

new Date("2026-03-01");            // midnight UTC
new Date("2026-03-01T00:00:00");   // midnight where the reader is

Paste both into a console and look at the gap. If you are on UTC the gap is zero, which is most of why this survives code review.

Where the day goes

Midnight is the worst possible instant to be ambiguous about, because it is the boundary. Any negative offset moves a UTC midnight backwards across it.

const d = new Date("2026-03-01");  // UTC
d.toLocaleDateString();            // the first of March, or the last day of February

Which one you get depends entirely on where the browser is. In UTC-5 that date renders as 28 February. The value never changed, the database is fine, your API response is fine, and the pixel on the screen says the wrong day for every visitor west of the meridian.

East of it the mirror case is waiting with any time late enough in the day.

Why it reaches production

Three things have to line up, and they usually do.

The team is in one timezone, often a European one where the offset is small and sometimes zero, so the bug is invisible in development. The test suite runs in CI with TZ unset or set to UTC, where the gap is exactly zero and the assertion passes forever. And the string that triggers it is produced a long way from the code that renders it, usually by a backend serialising a date column, so nobody reading either file sees both halves at once.

Then somebody adds or removes a time component for an unrelated reason, a formatter changes, an API starts returning a full timestamp instead of a date, and the interpretation silently flips for users you cannot see.

What to do instead

Do not hand an ambiguous string to the constructor and hope. Say which one you mean.

// Explicitly UTC, from parts
new Date(Date.UTC(2026, 2, 1));

// Explicitly a fixed instant, with an offset in the string
new Date("2026-03-01T00:00:00Z");

// Rendering a calendar date, where no instant is involved at all
d.toLocaleDateString(undefined, { timeZone: "UTC" });

That last one matters more than it looks. A delivery date, a birthday and an invoice date are not instants. They are labels on a calendar, and converting them to a point on a timeline is the whole mistake. If you never want the reader's clock involved, say so at the formatting end too.

And treat any format outside the spec's as a coin toss. MDN's own note is that the section describing them "contains implementation-specific behavior that may be inconsistent across browsers or different versions of browsers", and the unreliability of Date.parse() is one of the stated motivations for Temporal existing.

The part that makes it expensive

The bug is deterministic. Given the string and the offset, it happens every single time.

But it is deterministic in a variable you do not have. The one fact that decides whether your reader sees the first of March or the twenty-eighth of February is their UTC offset at the moment they loaded the page, and that is not in the ticket, not in your logs, and not something they know to tell you. They will say the date is wrong, which is true, and you will fail to reproduce it, which is also true.

It is the ordinary shape of the reports that take longest: not hard to understand once you see it, and impossible to see from where you are standing.

"I Can't Reach the Button" Is Unreproducible on Your Desktop, and `100vh` Is Why

Vladimir Elchinov — Thu, 15 Oct 2026 12:59:43 +0000

A report comes in: the submit button at the bottom of a full-height section cannot be tapped. You open the page on your desktop. Fine. You open the responsive emulator at the phone's exact dimensions. Also fine. You close the ticket.

The reporter was right, and so were you. The difference is a browser interface neither of you was looking at.

`vh` is not the height of the screen

It is the height of the screen with the URL bar taken away. Not as a bug, and not as an implementation detail somebody will fix. It is what the unit is specified to mean.

CSS Values and Units Level 4 defines three viewport sizes. The small viewport is "the viewport sized assuming any UA interfaces that are dynamically expanded and retracted to be expanded". The large viewport is the same sentence with the last word changed to "retracted". And then the part that catches people:

The large viewport-percentage units (lv*) and default viewport-percentage units (v*) are defined with respect to the large viewport size.

The default units. vh is lvh. Your 100vh section is laid out as though the URL bar is not there, on a device where it is there until the user scrolls.

So on first paint, before anybody has scrolled, the bottom of that section is underneath the browser chrome. The button is on the page, it is rendered, it has non-zero dimensions, and your tests will say so. It is just not somewhere a thumb can go.

Why it was specified that way

Not an oversight. The alternative is worse.

If vh tracked the bar as it retracted, every full-height element would reflow mid-scroll. Headers would jump, a sticky footer would walk up the screen, and text would reparagraph under the reader's eyes while they were reading it. Pinning vh to the larger of the two sizes buys you a unit that holds still. The cost is that it is wrong by the height of the bar at exactly the moment most people see your page for the first time.

You can see all three at once:

const probe = document.createElement('div');
probe.style.position = 'absolute';   // out of flow, so measuring cannot move the page
probe.style.visibility = 'hidden';
document.body.append(probe);

for (const unit of ['vh', 'svh', 'lvh', 'dvh']) {
  // An unsupported unit is an invalid declaration, which leaves the previous
  // value in place and would print the last unit's number as if it were this one.
  if (!CSS.supports('height', `100${unit}`)) {
    console.log(unit, 'not supported here');
    continue;
  }
  probe.style.height = `100${unit}`;
  console.log(unit, probe.getBoundingClientRect().height);
}

probe.remove();
console.log('innerHeight', window.innerHeight);
console.log('visualViewport', window.visualViewport?.height);

On a desktop browser every number is the same, which is the entire reason this never shows up while you are working. On a phone, before you scroll, svh and lvh differ by the height of the bar and vh sits with lvh.

The fix you reach for is the one the spec warns about

Having found dvh, the obvious move is to swap it in everywhere. The specification gets ahead of you:

The sizes of the dynamic viewport-percentage units are not stable even while the viewport itself is unchanged. Using these units can cause content to resize e.g. while the user scrolls the page.

That is the reflow problem you just opted back into. dvh is right where a resize mid-scroll is genuinely harmless. For anything that has to be reachable without scrolling - a primary action, a dismiss control, a cookie banner's accept button - svh is the honest unit, because it is the one that assumes the chrome is in the way. The layout is slightly short when the bar retracts. Nobody has ever filed a ticket about slightly short.

What the report could not have told you

Here is the part that generalises past this one unit.

Ask the reporter what their viewport was and they will send you a screen size, because that is the number a phone knows about itself. It is the wrong number. What decided the layout was whether a piece of browser furniture was expanded at that moment, which is not a device property, not a setting, and not something they can observe. It depends on whether they arrived from a link or a home screen icon, and on whether they had scrolled yet.

A screenshot does not settle it either. The screenshot shows the visual viewport. Your CSS was reasoning about the large one. Those are the two numbers whose disagreement is the whole bug, and the image contains only one of them.

Which is the shape of most unreproducible reports, once you look at them: the fact that would decide it is not hidden, it is just not a fact the person in front of the problem is able to know they should write down.

DEV Community: Session Replay

Your Number Input Reads Empty, and the User Did Type Something

The rule that erases it

The part that actually costs you

The one field that knows

Worth knowing: the sibling behaves differently

Why you will never see it

The Button Moved Before Your Finger Landed, and Your Click Handler Is Innocent

The browser already has a defence, and you have probably never configured it

The measurement has a blind spot exactly where it hurts

Record the shifts you are told to ignore

Why the report will never contain this

Your Error Tracker Shows Zero Crashes Because It Lives Inside the Thing That Crashed

The structural problem, not a missing feature

What works is a header, not a script

Three things that will make you think it is broken

What actually arrives

Why that one field is the whole diagnosis

The thing to do, and the thing to ask

Browser Zoom Changes the Size of a CSS Pixel, and Your Bug Report Cannot See It

Zoom is not magnification

They will not tell you, because they do not know

The number you would reach for cannot answer it

Record the decision, not the zoom

The ceiling on asking

In a Background Tab, setInterval(fn, 1000) Runs Once a Minute

The rule, in Chrome's own words

Your code is "chained" whether you meant it or not

The bug this actually causes

Why you will never see it yourself

What reaches you instead

Your Autoplay Works Because Chrome Has Learned to Trust You

The score is real and you can read it

Which makes this worse than ordinary unrepresentativeness

Meanwhile the failure is silent by default

Why the report will not say any of this

Your Tab Was Discarded, and Nothing in Your Code Was Told

What actually happened

Why nothing in your code noticed either

What it costs you, which is more than one empty form

The one fact that settles it

Why this reaches you as an unreproducible report

`localStorage.clear()` Tells Your Other Tabs Nothing They Are Listening For

The event you are listening for deliberately skips you

The event the other tabs get has no key on it

Why nobody reports this usefully

sessionStorage is not the way out

Every Origin Your Page Talks To, and the Four Traps in Listing Them

The cheap version, and what it misses

The version that covers pages you never visit

Why the list is worth having before you need it

Your await Can Spend the User's Gesture Before You Use It

The rule you are up against

The shape that fails

It is a cluster, not one bug

Why beforeunload is not like this

What to do about it

The part that makes it expensive

Two Date Strings One Character Apart Land on Different Days

The rule

Where the day goes

Why it reaches production

What to do instead

The part that makes it expensive

"I Can't Reach the Button" Is Unreproducible on Your Desktop, and `100vh` Is Why

vh is not the height of the screen

Why it was specified that way

The fix you reach for is the one the spec warns about

What the report could not have told you

Why `beforeunload` is not like this

`vh` is not the height of the screen