Recipes

Real frictions, sorted by the situation you are in. Written after being stuck, not before.

Every page in this section started as something that did not work. One hundred and six frictions were on record in the project’s field notes on 2 August 2026; the eight recipes here are the ones that recur often enough to deserve a page of their own.

None of them was written in advance. A recipe that anticipates a problem describes the problem its author imagined; a recipe written after being stuck describes the one that actually happens.

Find yours by symptom

What you are seeing	Go to
The click reports success and nothing moved	Element that will not click
The form submits and the page does not change	Form that never submits
Navigation times out on a page that keeps loading	Page that never settles
You are back on the login screen between two calls	Session lost between calls
The element is visible but no selector reaches it	Element inside an iframe
The right number clicked the wrong row	Clicked the wrong element
A slow operation runs and you see nothing until it ends	Long operation, no feedback
Login works, then the target asks for a six-digit code	Second factor

The one that costs the most to learn the hard way

A timeout on a click does not mean the action failed.

A real case, from the field log: a clone was launched by a form submission that kept the HTTP request open for the whole server-side operation. Playwright gave up after the default timeout and reported an error. The operation had already started. Re-run “properly” with a longer timeout, it produced a second identical clone — which is how anyone found out the first had succeeded.

Check the target before retrying. That sentence is worth more than the rest of this page.

Why they are published

A failure mode that stays private gets rediscovered by everyone, one at a time. These pages exist so that the second person to hit the problem spends five minutes on it rather than an evening.

In detail

The session does not survive between two calls — You log in, the capture proves it worked, and the next call lands back on the login page — or worse, reports success and does nothing. What is actually happening, and the rule that avoids it.

The element is there, and the click does nothing — The capture shows the button. Set-of-Mark numbers it. The click reports success, and nothing moves. Three escalation levels, in the order to try them.

The form reports success and never submits — The click succeeds, the scenario ends green, and the server received nothing. Two different causes produce this exact result — and the fix for one does not fix the other.

The operation takes minutes, and you see nothing until it ends — A clone, an import, a bulk update. Diwall captures at the end — so a failure at thirty seconds costs you the full wait. How to get intermediate views, and why a timeout is not a failure.

It clicked, but not on the element you meant — Three identical buttons, a list that grew by four rows, a banner that closed between the capture and the click. The number was right and the target was wrong.

The page never finishes loading, whatever timeout you set — Ten seconds fails. Forty-five seconds fails identically. The target is not slow — it is never going to be finished, and no timeout will change that.

The element is inside an iframe and Set-of-Mark ignores it — A payment widget, an embedded editor, a third-party form. The numbering stops at the frame border — and that border is a browser security boundary, not an oversight.

The target asks for a second factor — Three ways through a 2FA prompt, depending on where the code comes from — and the one case none of them covers, which you will meet on the day you enrol.