DEV Community: Arafat Islam

Exit intent that works on mobile, not just desktop

Arafat Islam — Wed, 24 Jun 2026 23:37:37 +0000

Originally published on my site, arafatcro.dev/guides.

You copy the exit-intent snippet, it fires nicely when the cursor heads for the close button, and you ship. Then you check the data and half your traffic never triggered it, because they were on phones and a phone has no cursor to chase. Exit intent is not one trick. It is a different signal on each device, fired once, and built so it does not become the thing people leave over.

The trick everyone copies

The standard snippet listens for the mouse leaving the top of the page. When the cursor crosses the top edge, heading for the tab bar or the close control, you call it intent to leave and show your overlay. On desktop it works.

The problem is that this signal only exists on a device with a pointer. On a phone or tablet there is no cursor, nothing ever leaves the top of the viewport, and that listener never fires. So the most common exit-intent implementation does nothing for anyone on a phone, which on a lot of sites is more than half the traffic. Nobody notices, because it looks like it is working on the desktop where you tested it.

Detect the device, use the signal that exists on it

On desktop it is the cursor arcing toward the browser chrome. On touch you read it from behaviour instead: a fast flick upward toward the address bar, or a stretch of inactivity. None is as crisp as the desktop signal, so you tune the thresholds rather than firing on the first twitch. Put both behind one helper so your variation code does not care which fired.

function exitIntent(callback, {
  sensitivity = 20,        // px from the top edge that counts as "leaving"
  mobileScrollDelta = 60,  // px of fast upward scroll that counts as a flick
  idle = 0,                // ms of inactivity before firing (0 = off)
  once = true,
} = {}) {
  let fired = false;
  let lastY = window.scrollY;
  let idleTimer;

  function teardown() {
    document.removeEventListener("mouseout", onMouseOut);
    window.removeEventListener("scroll", onScroll);
    clearTimeout(idleTimer);
  }

  const trigger = () => {
    if (fired) return;
    if (once) fired = true;
    teardown();
    callback();
  };

  const onMouseOut = (e) => {
    if (!e.relatedTarget && e.clientY <= sensitivity) trigger();
  };

  const resetIdle = () => {
    clearTimeout(idleTimer);
    idleTimer = setTimeout(trigger, idle);
  };

  const onScroll = () => {
    const y = window.scrollY;
    if (lastY - y > mobileScrollDelta) trigger(); // fast flick upward
    lastY = y;
    if (idle) resetIdle();
  };

  document.addEventListener("mouseout", onMouseOut);
  window.addEventListener("scroll", onScroll, { passive: true });
  if (idle) resetIdle();

  return teardown;
}

This helper lives in ab-test-helpers, a small set of dependency-free helpers for client side tests.

Fire once, and do not nag

An overlay that reappears on every page stops being a save and becomes the reason someone leaves. Fire the detector once per session, and remember a dismissal so a visitor who said no is not asked again.

function allowOncePerDays(key, days = 7) {
  const name = `fc_${key}`;
  try {
    const until = Number(localStorage.getItem(name) || 0);
    if (Date.now() < until) return false;
    localStorage.setItem(name, String(Date.now() + days * 864e5));
    return true;
  } catch (e) {
    return true; // storage blocked: do not suppress
  }
}

exitIntent(() => {
  if (sessionStorage.getItem("exit_dismissed") === "1") return;
  if (!allowOncePerDays("exit_offer", 14)) return;
  showOverlay();
}, { idle: 20000 });

It is a modal, so make it accessible

The overlay is a dialog. Trap focus inside it, return focus on close, let Escape dismiss it, and give it the ARIA roles a screen reader needs. Skip these and a keyboard user is trapped behind it or lost on the page underneath.

Measure the intent, not just the impression

Fire an analytics event when leave intent is detected, separate from whether the overlay rendered. Then the control group logs exit intent too, and you can measure how often it happens and how the variation changed behaviour, not just count the people who saw the modal.

The short version

Exit intent is a desktop signal plus a couple of touch signals, behind one detector that fires once. Cap it so it does not nag, build it as a real dialog with a focus trap, and log the detection separately from the popup. Do that and it works for everyone, not just the half on a laptop.

I write up the hard parts of client side A/B testing at arafatcro.dev/guides. The full version of this post, with a comparison table of every signal, is here.

Why your A/B test variation won't stick on a React input

Arafat Islam — Wed, 24 Jun 2026 19:12:37 +0000

You write the variation, set the input's value, and it looks right for a frame. Then React renders and your value is gone. Or it stays on screen but the submit button stays dead, because nothing told React anything changed. Setting the value the normal DOM way does not work on a controlled input, and the reason is worth knowing before you waste an afternoon on it.

The symptom

Your variation sets a field for the user. It prefills a postcode or bumps a quantity. For a moment it is there. Then React renders again from its own state and puts the old value back, so the change flickers and disappears. Or the value holds on screen, but everything that should follow it does not happen. The form stays invalid. The button never enables. The app simply did not notice.

Why React ignores a direct value change

In React an input is a controlled component. React owns its value through state, routes events through its own synthetic system, and keeps a private record of what the input last held. When you set input.value directly you change the DOM node, but you do not touch that private record, so React believes nothing happened. No synthetic onChange fires, and on the next render React writes its own state value straight back over yours. You changed the pixels, not the state, and in React the state always wins.

The fix: set the value the way React expects

Set the value through the native setter on the element prototype, which updates the record React is watching, then dispatch a real input event that bubbles. Now React sees a genuine change, runs its onChange, and the rest of the app catches up the way it would for a real keystroke. None of this is Optimizely specific. It is the same in VWO, Convert, Adobe Target, or any tool that hands you client side JavaScript.

// Set a React controlled input so React's own tracker updates and onChange fires.
function setReactValue(input, value) {
  const nativeSetter = Object.getOwnPropertyDescriptor(
    window.HTMLInputElement.prototype,
    "value"
  ).set;
  nativeSetter.call(input, value);
  // Fire both: some host handlers react to input, others only to change.
  input.dispatchEvent(new Event("input", { bubbles: true }));
  input.dispatchEvent(new Event("change", { bubbles: true }));
}

// A textarea or a select needs its own prototype:
// HTMLTextAreaElement.prototype or HTMLSelectElement.prototype
// Checkboxes and radios track "checked", not "value", so they need their own path.

This helper, and a handful of others for the usual client side testing problems, lives in a small dependency-free repo: ab-test-helpers. Copy what you need.

Inputs are not the only thing React reclaims

The same ownership bites when you inject elements. Drop a node inside a container React manages and its next render can wipe it out, because that node is not in React's picture of the tree. Mount your own markup into a stable element outside the app root, or be ready to put it back when the view changes. Treat anything inside React's tree as borrowed, not yours.

How this played out on a real build

This came up building a custom quantity stepper on Screwfix. The product pages run on Next.js and the quantity field is React controlled, so adding my own plus and minus buttons hit the usual wall. Setting the value moved the number on screen, but the basket total and the stock check both ignored it, because React never saw a change.

Going through the native value setter and then firing both an input and a change event fixed it. React picked up the new number, and everything that keys off quantity recalculated as if the shopper had typed it. I fired both events on purpose, because some of the host's handlers listened for one and some for the other.

Ways to set a React controlled input

Approach	Does React's state update?	Reliability
Plain `el.value = x`	No. You change the DOM node, not React's tracked value, so onChange never fires	Unreliable. React overwrites it on the next render
`el.value = x` then dispatch an `input` event	Sometimes. The event fires, but React compares against its stale tracked value and can skip the update	Flaky. Works on some versions and inputs, fails on others
Native value setter, then dispatch `input`	Yes. The setter updates the tracked value and the event makes React read it	Reliable. This is the fix
Simulating keystrokes (`keydown` / `keypress`)	No. Synthetic key events do not change the value, and React ignores untrusted key events for input	Unreliable. Looks plausible, almost never works

Common questions

Why doesn't my A/B test value stick on a React input?

You set input.value directly, which changes the DOM node but not the private record React keeps of the input's value. React thinks nothing happened, so on its next render it writes its own state value back over yours and the change disappears.

How do I set a React controlled input's value from JavaScript?

Set the value through the native setter on the element prototype, Object.getOwnPropertyDescriptor(window.HTMLInputElement.prototype, 'value').set, called against the input. Then dispatch a bubbling input event so React's synthetic event system runs and state updates.

Why doesn't onChange fire when I set the input value in code?

Setting input.value does not dispatch any event, and React's onChange only runs from its own synthetic event. Dispatch a real input event that bubbles after setting the value, which is what React listens for, so its onChange runs and the app's state catches up.

Do I need the native value setter, or is dispatching an event enough?

You need both. Dispatching an input event without the native setter still leaves React's private value record stale, so React can ignore the change or reset it. The native setter updates that record, and the event tells React to read it.

Does this work for textareas and selects too?

The same idea applies, but each tag has its own prototype. Use HTMLTextAreaElement.prototype for a textarea and HTMLSelectElement.prototype for a select. Checkboxes and radios track checked rather than value, so they need their own setter and a click or change event.

The short version

If a value you set will not stick, or the app ignores it, you are setting it behind React's back. Go through the native setter, fire a real input event so onChange runs, and keep your own markup out of the parts React redraws.

I write up the hard parts of client side A/B testing at arafatcro.dev/guides. If this saved you an afternoon, the SPA route-change guide and the waitForElement guide cover the next two walls you will hit.