This is the story of how I lost an entire day trying to automate posting on note (a Japanese blogging platform).

The title and body went in fine through browser automation (by faking a paste event into the ProseMirror editor). On the hashtag and price settings screen, too, if I set a value on the input element and fired input/change events, the hashtags showed up as chips on screen and it looked like it had worked.

But when I came back to the same settings screen a while later, both the price and the hashtags had reverted to their defaults.

What was going on

Set 5 hashtags → set the price to ¥980 → everything looks right on screen (chips displayed, values filled in) → step away for a bit → come back to the same screen tens of minutes later → the price is back to ¥300 (the default), and the hashtags are back to the 5 auto-suggested ones.

Looking at the browser’s network log, not a single API request containing price or hashtag had ever been sent.

In other words, firing input and change events to change what the screen shows was a different thing from the value being saved to the server. This settings panel didn’t auto-save field by field. It was built to send everything at once when you go all the way through a series of screens and press the “Publish” (投稿する) or “Update” (更新する) button at the end.

The correct procedure

  1. Set the hashtags, price, and so on
  2. Without reloading the page and without a gap, click the button that moves on to the next step of the publishing flow (the “Paid area settings” step for a paid article, otherwise the next confirmation screen)
  3. On the final confirmation screen, press “Publish” (or “Update”)

If you close the tab, reload, or leave it sitting for a long time partway through, everything you’ve entered is lost, because until then it only exists as temporary state in the browser.

Another trap: the “Saving” indicator can look frozen

Right after pressing “Publish,” the button sometimes looked stuck showing “Saving” for a long time.

In reality, the transition to the next screen was in progress. Checking document.readyState showed it sitting at complete, and the console was full of failed to fetch errors from tracking scripts (caused by an ad blocker or extensions blocking analytics requests, and unrelated to the actual posting process). If I just waited a few seconds without panicking, it moved on to the correct next screen (publish settings → the article page).

Summary

  • Some services don’t save anything to the server just because you set a value on a form element and fire input/change events
  • If saving really happens as “one bulk submit when you press the final send button,” trusting the intermediate state and reloading wipes everything out
  • If you’re automating this, the safe approach is to run everything from setting the values to the final submit as one continuous sequence, with no reloads in between
  • When a “Saving” indicator looks frozen, don’t judge it by unrelated tracking script errors; judge it by what the page navigation is actually doing