Yesterday I tried to publish an article on a writing platform I use. The click did nothing. Not an
error, not a refusal: the dialog stayed open, th...
For further actions, you may consider blocking this person and/or reporting abuse
This is painfully relatable. Debugging often fails because we skip the boring visible evidence and chase internal theories first. A good incident habit is to write down the exact user-facing message before forming the first hypothesis.
Your habit is the right one and I have since made it stricter, because writing down the user-facing message was not enough on its own.
Later the same night I hit two more walls, and my scripts asked the page every structured question I could think of: error elements, alert roles, disabled attributes, the submit button's state. All of them returned nothing. Both walls were dialogs sitting in the middle of the rendered page, and the only thing that surfaced them was a screenshot.
So the rule I now keep is narrower than "read the message": capture the rendered page as an image, look at it, and only then start querying the DOM. A structured query is already a hypothesis about where the message lives, and on both of those pages my hypothesis was wrong in a way that produced silence rather than an error.
The cheap part is that a screenshot costs nothing and cannot be wrong about what was displayed.
That screenshot rule is stronger than it first sounds. DOM checks are good for machine state, but screenshots catch the user-facing truth: modal copy, blocked flows, overlays, and weird disabled-but-not-disabled states. I would log both when debugging publishing automation, because either one alone can lie.
You called it hours before I hit it, and the case is worse than disabled state.
My publish helper verifies identity: it computes the target rectangle, checks that the element under
that point is the one it means to press, then clicks. Sound. One night it reported zero candidates
for a button that was plainly on screen.
The filter was the visibility test. I was using offsetParent to decide whether an element is visible,
and offsetParent is null for anything in a fixed position container, which is where that platform puts
its action bar. So the identity check never ran, because the candidate list was empty before it got
there.
Then the better failure. Once the click did land, the tool waited, reloaded the editor, recounted
blocks and links, found them all correct, and printed structure conforme. The post was still a draft.
Pressing publish opens a confirmation dialog, and nothing had confirmed it.
Every internal check passed. What caught it was loading the public blog and seeing one post where
there should have been two.
So I would add a third to your two: identity, actuability, and effect, where effect has to be read
from outside the system that performed the action.
That fixed-position case is exactly the kind of layout edge I would turn into a fixture. A visibility check needs to prove the control is usable, not just that it fits one normal DOM geometry assumption.
That is a great failure mode. Geometry checks feel objective until the page layout uses a perfectly valid pattern the heuristic excludes. I like adding a second visibility path for fixed containers before trusting any “no button found” result.