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. The fix was also wrong
6. Real cause 2: the form reloads itself
7. What the two bugs have in common
8. What changed in the procedure
9. The trap that survived
10. 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 was also wrong

We switched to a triple click, which selects the paragraph in a way the field recognises. It worked on the next video, we logged it as solved, and moved on.

It was not solved. A triple click selects one line. A title that wraps to two lines — and all of ours are long sentences — leaves a remainder: the new text goes in and the tail of the old line stays. The symptom shifts from "reverted to the filename" to "title with junk at the end", which is quieter and therefore slips through more easily.

The sequence that actually works has nothing elegant about it:

click the field
key: ctrl+End          -> go to the end
key: ctrl+shift+Home   -> select backwards to the start
key: Delete            -> clear the selection
type "<text>"

That Delete on the fourth line is not redundancy. Without it a stray character survived and produced a published title reading IIA corrigindo — yes, it went out like that. Typing over a selection should replace it; in this field, sometimes it does not.

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, and explained it precisely: processing time tracks file size.

Half a minute is a short enough window that you type, save, and never notice a window existed. Five minutes is long enough to lose everything. Same procedure, same operator, same day — and the outcome depended on the weight of the .mp4.

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. Always clear with ctrl+End + ctrl+shift+Home + Delete, in both the title and

the description. Never ctrl+a, never a triple click.

1. 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

— and wait seven seconds after it opens, because the screen accepts clicks before it has finished mounting.

With that, the next video was scheduled with correct title, description, rating and time — zero rework. So were the two after it.

The trap that survived

One thing kept going wrong even with a stable recipe: clicking the "Visibility" tab. The coordinate resolved for it sometimes lands on the video preview player, which opens fullscreen and closes the dialog, taking any unsaved input with it. It happened three times.

The alternative is ugly and it works: click "Next" in the footer three times instead of jumping straight to the tab. The footer never overlaps the player. We traded a three-click shortcut for three extra clicks, deliberately.

The cost, in numbers

At the start, each video cost roughly 25 browser interactions. With the stable recipe — wait for the check, clear the field correctly, use the footer instead of the tab — it dropped to about 10.

For the 35 videos remaining after the first batch, that is the difference between ~875 and ~350 interactions. Neither number is good. 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?

Not usefully. The selection happens in the DOM, but React never registers it as a state change: typed text merges with the previous content and the app discards the result. A triple click does not fix it either — it selects a single line, and long titles wrap to two. The only sequence that worked in every case was ctrl+End, ctrl+shift+Home, Delete, then type.

Why the extra Delete, if typing over a selection already replaces it?

It should replace it. In this field a character from the previous selection sometimes survives. That is how one video went out titled 'IIA corrigindo'. The Delete costs one keystroke and removes the whole class of error.

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.