The Hunt for justify-content

What happened, second by second

The visitor is learning CSS layout. They know what they want to do: centre a row of items. They don't remember the property name. Here is their visit as the recording tells it.

1. 0:00

   Lands on CSS Flexbox. A consent dialog covers the page and the document is scroll-locked (data-fast-cmp-locked on <html>). In the replay it shows as a grey veil: the dialog itself is drawn inside a shadow root, which the snapshot doesn't include.

2. 0:25

   The lock attribute disappears and the dialog's class flips off: the visitor declined. The click itself isn't in the recording, because the consent manager draws its buttons where the logger can't see them. Keep that blind spot in mind when reading any replay of a consented page.

3. 0:36

   Three clicks in a hundred milliseconds on Item 3 of the blue demo container. The grey tiles look like buttons. They are an <h3> inside a static figure, so nothing happens.

4. 0:38

   Reads down the page in three scrolls, past a 300 px ad container that stays empty except for a Remove ads link.

5. 0:57

   Clicks the magnifier in the top bar. The search field slides open and the visitor types justify content center. The recording shows no input events for the next sixteen seconds: the field opened without focus, so every keystroke went to the page.

6. 1:13

   Clicks into the field and types again. The input arrives at 1:14 with justify content; the suggestion list offers CSS Flexbox Container, and the visitor takes it at 1:22.

7. 1:42

   The second page, CSS Flex Container. Its property list mentions justify-content fifth from the top.

8. 2:01

   Two clicks on that mention, a second apart. It is a <code> label, not a link.

9. 2:04

   Scrolls 6,081 px in six moves through flex-direction, flex-wrap and flex-flow. None of them is the property they came for.

10. 2:25

    At the bottom, a section called Flex Container Subpages finally links to justify-content. The cursor rests on it as the session ends, 100 seconds after the search began.

What the replay tells the team

A single session is an anecdote, so treat these as leads to check against many sessions, not conclusions. Each one links to the moment in the recording that shows it. For how to turn findings like these into product work, see from rage clicks to roadmap.

How this recording was made

The LogNroll SDK loads a logger that snapshots the page, then records mutations, clicks, scrolls, inputs, console output and network calls. Its save-local mode also keeps every event in the browser's private file storage, so a session can be exported as a file. On a site you don't own, you can switch it on from the browser console:

// 1. Keep events locally, starting from a clean capture
localStorage.setItem('lnr-save-local', '1');
localStorage.setItem('lnr-save-local-reset', '1');

// 2. Load the SDK and start a session
const s = document.createElement('script');
s.src = 'https://cdn.jsdelivr.net/npm/@lognroll/[email protected]/dist/index.js';
s.onload = () => LognRoll.initSession('<your company id>', {});
document.head.appendChild(s);

// 3. Browse. On each new page, run step 2 again: the logger
//    restores earlier events from storage and keeps appending.

// 4. Export everything as one file
logger.downloadSession();

The visit was driven by an AI agent in a browser on 9 November 2026, following a realistic task, so the visitor here is a stand-in, not a member of the public. Read it as a demonstration of how to use replay, not as research about w3schools' users.

Before publishing, the file was cleaned: the logger's own retry warnings, the device's language and user agent, and the consent manager's user ID and country were removed, the same kind of scrubbing we recommend in privacy-first session recording. The page's stylesheets, fonts and images were packed into a separate asset bundle so the replay renders without loading anything from the original site.

The embedded player

The player on this page is a small web component that reads an exported session from a URL. It decodes the file in the browser (a stream of timestamped points: snapshot HTML, mutation records, clicks, scrolls, inputs, console and network entries), rebuilds the page inside a sandboxed frame with scripts disabled, and replays mutations in order. Seeking backwards reloads the nearest snapshot and fast-forwards. If you want the engineering detail, we cover the same pipeline in session replay architecture.

<script src="https://lognroll.com/replays/player.js"></script>
<lnr-replay src="session.bin.gz" assets="assets.json.gz"></lnr-replay>

Rage and dead clicks are flagged by simple rules: three or more clicks within 1.2 seconds and 40 px of each other, or a click on an element that isn't interactive. You can also download this recording (gzipped) and open it in the LogNroll player after unzipping.

Try it on your own site

Every finding above came from one recording and about ten minutes of watching. On your own product, start from a filter rather than random sessions: sessions with an error, sessions that abandoned a step, or sessions with rage clicks. LogNroll bundles session replay, heatmaps, error tracking and product analytics, with a free tier of 1,000 sessions per month.