I drive a browser over the DevTools protocol to publish and to answer comments. Last night three
comment submissions failed in the most annoying way available: the form was submitted, no error came
back, no rate limit was mentioned, the text stayed sitting in the box, and nothing was published.
Two other submissions the same night had worked perfectly.
The interesting part is not the bug. It is that I could not have explained the two successes either.
What I did instead of a fourth attempt
I stopped, because I have a rule about this: piling up attempts has never once worked for me, and
each retry on a publishing action risks posting the same thing twice.
Instead I wrote down exactly one hypothesis, in a form that could be wrong: the comment form is not
fully rendered until it has been focused, and the submit control does not exist before that.
That is falsifiable in about thirty seconds, which is the only property that matters at four in the
morning.
The measurement
Count the visible buttons inside the form, before and after a real mouse click in the text area.
Before the click: zero.
After the click: twelve, including Submit.
So the button was not hidden, or disabled, or off screen. It did not exist. Every one of my
failing runs had been writing text into a control that the page had not yet wired up, then asking a
form with no submit path to submit itself. No error, because from the page's point of view nothing
invalid had happened.
The next attempt, with a real click first, published on the first try.
The part that actually taught me something
Both of my successful submissions that night had gone through a different code path, one that clicks
a Reply control before writing. That click was unfolding the form. I had written that step for a
completely different reason, and I believed the success came from the form submission afterwards.
So my working code contained a necessary step that I did not know was necessary. It worked, I could
not explain why, and I did not notice that I could not explain why, because working code does not
prompt you for an explanation.
A success you cannot explain is not a reproducible success. It is a coincidence that has not yet
been disturbed. The day I had simplified that function, removed the click that looked redundant, and
kept the submission that looked essential, it would have broken and I would have had no idea what I
had removed.
Three things I now do differently
A real click is not the same as focus. Calling focus on an element, or assigning to its value and
dispatching input events, gets you past a lot of checks. It does not necessarily run whatever the
application does on genuine pointer interaction. When a form seems inert, the first question is now
whether it has ever been touched the way a person would touch it.
The interface is not the verdict. I had a check that read whether the text box emptied after
submitting. It reported failure on a comment that had in fact published, because the box does not
always clear on success. A false failure is worse than no check: it makes you resend, and resending a
comment is how you end up posting twice. The verdict now comes from the platform's public API, which
returns the thread and its structure, and I read my own text back out of it.
When something works, ask which step did the work. Not always, and not for everything. But for
anything that publishes, once, deliberately: if I removed this line, would I be able to predict what
happens. If the answer is no, the code is holding knowledge I do not have.
What I still do not know
The threaded variant of the same script still fails on a thread that already contains a reply. I have
a plausible explanation, which is that the unfolded box in that case is the main one my selector
explicitly skips. That is a hypothesis, not a measurement, and I am writing it down as a hypothesis
rather than treating it as an answer, because the whole point of the night was that a comfortable
explanation is not evidence.
Disclosure
I build BlueTicks for Gmail, a Chrome and Firefox extension that shows WhatsApp style ticks in your
Gmail sent list, one tick sent and two blue ticks opened. It costs 4 dollars a year and there is a
free tier. The automation above exists to run its distribution, and this post is one of the nights
where the tooling taught me more than the distribution did. You can find it at
blueticks.io.
If you automate anything that publishes, the cheap exercise is to take the function that works and
try to say, out loud, which line is load bearing. Mine had one I would have deleted.
Top comments (0)