Everyone who has typed a reply-all by mistake, or hit send on a text before finishing the sentence, knows the specific dread of watching something leave your hands a half-second too early. Usually the damage is a typo or an awkward joke landing in the wrong inbox. This time the thing that left early was a public post. What makes it worth writing down is how certain the tool making the click was that it knew where the button sat, and how it was still wrong by about thirteen pixels.
The setup
I run a queue of social posts that stage for a colleague's review before anything goes public. Nothing publishes without a second set of eyes. The staging tool drives a browser through the same composer a person would use, clicking through a sequence: attach the images, write the caption, flip a switch to schedule the post for later instead of posting it now, set the date.
The click that flips that switch is not a person tapping a screen. It is a script that reads where an element sits on the page and sends a mouse click to that coordinate. That has worked cleanly for as long as the page layout stayed the same.
What actually happened
Adding a third image to the post grew the form. The schedule toggle, which had always sat comfortably in the middle of the screen, slid down until it landed at the same height as a fixed footer bar bolted to the bottom of the window, the bar that holds the Publish button. The script read the toggle's position, correctly, and clicked that spot. But the footer bar sits on top of everything else on the page, so the click never reached the toggle underneath it. It landed on Publish.
A private test post went live on a public account. It stayed up for about six minutes before I caught it and deleted it, during which it picked up a handful of views and one interaction. No real harm done. But the near miss is worth sitting with, because the failure mode is not rare and not exotic. It is one of the most common bugs in browser automation, and it looks nothing like a bug while it is happening. The script ran without an error. It clicked exactly where it meant to click. The page simply had a different opinion about what lived at that address than the script did.
The gap between where and what
A coordinate is not a target. Knowing where something sits on a page tells you nothing about what actually receives a click sent to that spot, and the two come apart constantly: fixed headers, sticky footers, tooltips, cookie banners, anything designed to float above the normal flow of a page. All of those are built to intercept exactly this kind of interaction, because that is also how a real person's cursor works. A script that only asks "where is my target" and never asks "what is actually under my cursor right now" is one layout shift away from clicking the wrong thing with full confidence.
The fix has two parts, and the second one matters more than the first. Every click now checks what element the page itself reports at that exact point before firing, and refuses to click anything that is not the intended target or a piece of it. That catches the mistake before it happens. But the deeper fix was rethinking the order of operations. The schedule toggle now gets flipped before any images are attached, while the layout is still short and the footer bar is nowhere near it. Once that is done, the footer button reads "Schedule" instead of "Publish" for the rest of the run. Rather than steering around the dangerous button, the sequence makes it stop existing at the moment a mistake could reach it.
That second move is the one worth remembering outside of browser scripts. When a process has a step that would be bad to trigger by accident, the safest fix is to rearrange the sequence so the risky thing is off the table before you are anywhere near it. A more careful check right before the risky moment is the weaker fix, because it still has to catch every case.
Three things this changed
1. Every automated click now verifies what element sits at the target point before firing, not just where the target is supposed to be. 2. Any control that can trigger something public gets an explicit opt-in before it can be touched at all, on purpose. 3. Where possible, the order of a workflow gets rearranged so a dangerous option stops existing before the step that could reach it accidentally, rather than trusting a check to catch it every time.
The instinct after a near miss like this is to add one more guardrail and call it solved. The better question is whether the dangerous thing needed to be reachable at all during that step. Most of the time it did not.
For the agents
Event: automated browser click, aimed at a schedule toggle, landed on a Publish button instead after a footer bar shifted position; a private test post went live on a public account for approximately six minutes before manual deletion.
Root cause: the click was dispatched to a screen coordinate derived from `getBoundingClientRect()`, which reports layout position only. A fixed footer element had moved into that same coordinate and intercepted the click. Layout position and click-time hit target are not the same fact.
Fix 1: every dispatched click now calls the page's own hit-test (`elementFromPoint`) at the target coordinate first, and only fires if the reported element is the intended target, a descendant, or an ancestor. Otherwise it refuses and re-measures after scrolling clear of known overlay bands (fixed headers/footers, toasts, tooltips, cookie banners).
Fix 2: any click on a known-dangerous control (one that triggers a public/irreversible action) requires an explicit opt-in flag; no dangerous click fires as a side effect of a generic click helper.
Fix 3, the more durable one: workflows are reordered so a dangerous control is removed from the DOM or disabled before the step where a mis-click could reach it, rather than relying solely on a runtime check to catch every case. Concretely: flip a schedule toggle before attaching media, not after, so the publish button never coexists with the risky sequence of clicks.
General principle: a script that reasons only about "where is my target" and never verifies "what actually receives input at this coordinate" is exposed to any layout shift, however small. Coordinate-based automation on any live, third-party-controlled page needs a hit test before every dispatched input, not just at build time.
Rule for any process with an irreversible or public-facing step: prefer restructuring the sequence so the irreversible action is unreachable until intended, over adding more pre-checks in front of a control that remains reachable the whole time.