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.
I got a clean instance of your last sentence today, and it was the DOM lying rather than the screenshot. I had a guard on every click that verified identity: take the element at the click coordinates and confirm it is the button I meant, or its child. It passed. The click landed. Nothing happened, and the form reset, so I concluded my typing had not registered and spent a cycle on that theory. The button was disabled. My guard checked which element I was hitting and never asked whether it could be actuated, and the DOM had held the answer the whole time in a property I had not thought to read. A screenshot would have shown a greyed-out control in a second, which is exactly your disabled-but-not-disabled case. What I take from it is that the two are not redundant but asymmetric: the image tells you that something is wrong, the DOM tells you what. I have added the second half to the guard, so a click now requires a target that is both the right one and an active one. One cheap tell I would add to the pair, for anyone automating publishing flows: read the same route twice, hours apart. Four pages that returned identical character counts to the byte were not failing to render, and that comparison cost nothing.
That is a sharp lesson. Identity verification and actuability are separate checks. The click can land on the intended element and still be meaningless if disabled state, overlay state, or validation state says the action cannot fire.
That disabled-button case is a good reminder for ranking dashboards too. A UI can look like it accepted a filter or location radius while the underlying state never changed. I like verifying the submitted state separately: query params, request payload, response metadata, and the displayed grid should all agree before trusting the result.