The video title kept reverting to the filename

In this post

1. The symptom
2. Wrong diagnosis 1: "the typing never landed"
3. Wrong diagnosis 2: "it's the Escape key"
4. Real cause 1: ctrl+a does not select what you think
5. Real cause 2: the form reloads itself
6. What the two bugs have in common
7. What changed in the procedure
8. The cost, in numbers

Publishing 38 vertical videos across six platforms looked like mechanical work. The kind of task you automate on a Saturday and forget about.

The seventh scheduled video went out with the title jornada 01 cena s s usuario abre o 1 and no description at all. The filename. In the title field. Scheduled.

It was not an isolated case, and the expensive part was not the rework — it was that we misdiagnosed it three times in a row.

The symptom

The flow was simple: upload, type the title, type the description, set the rating, schedule. The screen confirmed everything. Reopening the draft minutes later, the title had reverted to the filename.

Not always. On some videos and not others — the worst kind of bug, intermittent enough that you blame the network, the latency, the day.

Wrong diagnosis 1: "the typing never landed"

Easy to rule out. A screenshot right after typing showed the correct title on screen. The text arrived. It disappeared later.

Wrong diagnosis 2: "it's the Escape key"

A misplaced click on the video preview opens fullscreen and hijacks the keyboard. The reflex is Escape. And here is the trap: the Escape that closes fullscreen is safe; the Escape inside a text field reverts the edit.

This genuinely happened — one video lost its title and description exactly that way. We fixed that case and the problem continued elsewhere.

Real cause 1: ctrl+a does not select what you think

The YouTube Studio title field is not an <input>. It is a contenteditable controlled by React.

Our pattern was the usual one:

ctrl+a        -> select all
type "title"  -> replace

In an <input> that works. In the Studio's contenteditable, the selection happens in the DOM but never becomes a React state change. The component sees typing on top of the previous content, and on save it discards the inconsistent result and falls back to the last known value: the filename.

The fix is embarrassingly small:

triple_click  -> selects the paragraph in a way the field recognises
type "title"

For multi-line fields such as the description, a triple click only grabs one line. There the answer is to go to the end and select backwards:

click the field
key: ctrl+End
key: ctrl+shift+Home
type "<text>"

That replaces everything regardless of line count.

Real cause 2: the form reloads itself

With ctrl+a fixed, the problem shrank. It did not disappear.

The clue was in the dialog footer, in a place we had been reading as decoration:

Checking 34%  ·  4 minutes left

While YouTube processes the video, the details form is periodically reloaded from the server — and each reload discards unsaved input. The field accepts text the whole time. It just does not keep it.

That explained the intermittency we had been attributing to luck: a small video processes fast and you finish in time; a larger one does not.

It also explained the one exception that made no sense. One video had come out perfect on the first try, because it was edited through the direct URL studio.youtube.com/video/<ID>/edit, days after upload — long after processing had finished.

The rule that stuck: only type after the footer says "Checks complete. No issues found." It takes one to five minutes. Waiting is cheaper than redoing.

What the two bugs have in common

The fourth row is the one that hurts. For six videos, our verification was a screenshot right after typing. The screenshot showed the right title. We were verifying the wrong thing, confidently.

What changed in the procedure

1. 1. Wait for "Checks complete" before touching any field.
2. 2. Triple click for the title; ctrl+End + ctrl+shift+Home for the description.
3. 3. After typing the title, the field grows and pushes the description down —

never click the description using a coordinate captured earlier.

1. 4. Verify the dialog header after saving, not after typing.
2. 5. Edit through the video's /edit URL, which opens the details screen directly.

With that, the next video was scheduled with correct title, description, rating and time — zero rework.

The cost, in numbers

Each video costs roughly 25 browser interactions. For the 35 remaining after the first batch, that is ~875 interactions. Feasible, slow and fragile — the three words together describe exactly the kind of task that should be an API call and not a browser session.

---

In part 2, the same problem shows up on six different platforms wearing a different disguise each time — and the rule that finally fixed it.

Frequently asked questions

Why not use the YouTube Data API instead of driving the Studio UI?

Because that is the right call and we were slow to make it. The v3 API handles upload, title, description, tags, rating and scheduling in a script — roughly 875 browser interactions become a few minutes. We started in the browser because a logged-in session already existed and it felt faster for 'just a few videos'. It was never a few videos.

Does ctrl+a work in a contenteditable field?

It works in the browser, but React does not register the selection as a state change, so typed text merges with the previous content and the app discards the result. A triple click selects the paragraph in a way the field recognises. For multi-line fields, ctrl+End followed by ctrl+shift+Home is more reliable.

How do you know the form is stable before typing?

In YouTube Studio the dialog footer shows 'Checking X% — N minutes left' while the video is processing. Only type after 'Checks complete'. It is the only reliable signal — the form looks editable long before it is.