O título do vídeo voltava a ser o nome do arquivo

Neste post

1. O sintoma
2. Diagnóstico errado nº 1: "a digitação não chegou"
3. Diagnóstico errado nº 2: "é o Escape"
4. Causa real nº 1: `ctrl+a` não seleciona o que você acha que seleciona
5. A correção também estava errada
6. Causa real nº 2: o formulário recarrega sozinho
7. O que os dois bugs têm em comum
8. O que mudou no procedimento
9. A armadilha que sobrou
10. O custo, em número
11. Um detalhe secundário que também custou

Publicar 38 vídeos verticais em seis plataformas parecia trabalho mecânico. É o tipo de tarefa que dá vontade de automatizar num sábado e esquecer.

O sétimo vídeo agendado, do JornadaSync, foi ao ar com o título jornada 01 cena s s usuario abre o 1 e sem descrição nenhuma. O nome do arquivo. No título. Agendado para o dia 11.

Não foi um caso isolado, e o mais caro não foi o retrabalho — foi que a gente diagnosticou errado três vezes seguidas.

O sintoma

O fluxo era simples: enviar o vídeo, digitar o título, digitar a descrição, marcar a classificação, agendar. A tela confirmava tudo. Reabrindo o rascunho minutos depois, o título tinha voltado ao nome do arquivo.

Não era sempre. Era em uns e não em outros, e essa é a pior categoria de bug: intermitente o suficiente para você culpar a rede, a latência, o dia.

Diagnóstico errado nº 1: "a digitação não chegou"

A primeira hipótese foi que o texto simplesmente não estava sendo digitado. Fácil de descartar: um screenshot logo depois de digitar mostrava o título correto na tela. O texto chegava. Ele sumia depois.

Diagnóstico errado nº 2: "é o Escape"

Um clique errado no preview do vídeo abre tela cheia e sequestra o teclado. O reflexo é apertar Escape. E aí vem a armadilha: o Escape que fecha a tela cheia é seguro; o Escape dentro de um campo de texto reverte a edição.

Isso aconteceu de verdade — o título e a descrição do EuRi foram perdidos exatamente assim. Só que corrigimos esse caso e o problema continuou nos outros.

Causa real nº 1: ctrl+a não seleciona o que você acha que seleciona

O campo de título do YouTube Studio não é um <input>. É um contenteditable controlado por React.

O padrão que usávamos era o de sempre:

ctrl+a          -> selecionar tudo
type "titulo"   -> substituir

No <input> isso funciona. No contenteditable do Studio, a seleção acontece no DOM mas não vira mudança de estado no React. O que o componente enxerga é uma digitação sobre o conteúdo anterior, e ao salvar ele descarta o resultado inconsistente e volta para o último valor conhecido: o nome do arquivo.

A correção também estava errada

Trocamos por triple_click, que seleciona o parágrafo de um jeito que o campo reconhece. Funcionou no JornadaSync, registramos como resolvido e seguimos.

Não estava resolvido. triple_click seleciona uma linha. Título que quebrou em duas linhas — e todos os nossos títulos são frases longas — fica com sobra: o texto novo entra e o resto da linha antiga continua lá. O sintoma muda de "voltou ao nome do arquivo" para "título com lixo no fim", que é mais discreto e por isso passa mais fácil.

A sequência que de fato resolve não tem nada de elegante:

click no campo
key: ctrl+End          -> vai para o fim
key: ctrl+shift+Home   -> seleciona de tras para frente, ate o inicio
key: Delete            -> apaga a selecao
type "<texto>"

O Delete da penúltima linha não é redundância. Sem ele sobrava um caractere solto que produziu um título publicado como IIA corrigindo — sim, foi ao ar assim. Digitar sobre uma seleção deveria substituí-la; nesse campo, às vezes não substitui.

Causa real nº 2: o formulário recarrega sozinho

Corrigido o ctrl+a, o problema diminuiu. Mas não sumiu.

A pista estava no rodapé do diálogo, num lugar que a gente lia como enfeite:

Verificação 34%  ·  4 minutos restantes

Enquanto o YouTube processa o vídeo, o formulário de detalhes é recarregado do servidor periodicamente — e cada recarga descarta o que estava digitado e não tinha sido salvo. O campo aceita texto o tempo todo. Ele só não guarda.

Isso explicava a intermitência que a gente vinha atribuindo à sorte, e explicava com precisão: o tempo de verificação acompanha o tamanho do arquivo.

Meio minuto de janela é curto o bastante para você digitar, salvar e nunca perceber que existia uma janela. Cinco minutos é longo o bastante para perder tudo. O mesmo procedimento, o mesmo operador, o mesmo dia — e o resultado dependia do peso do .mp4.

E explicava a única exceção que não fazia sentido nenhum: o Aprovalux tinha saído perfeito de primeira. Porque ele foi editado pela URL direta studio.youtube.com/video/<ID>/edit, dias depois do upload — com o vídeo já processado havia muito tempo.

A regra que ficou: só digitar depois que o rodapé disser "Verificações concluídas. Nenhum problema foi encontrado." Leva de 1 a 5 minutos. Esperar é mais barato que refazer.

O que os dois bugs têm em comum

Nenhum dos dois é bug do YouTube. Os dois são premissa nossa não conferida:

A quarta linha é a que dói. Durante seis vídeos, a verificação que fizemos foi tirar um screenshot logo depois de digitar. O screenshot mostrava o título certo. Nós estávamos verificando a coisa errada, e com confiança.

O que mudou no procedimento

1. 1. Esperar "Verificações concluídas" antes de tocar em qualquer campo.
2. 2. Limpar sempre com ctrl+End + ctrl+shift+Home + Delete, no título e na

descrição. Nunca ctrl+a, nunca triple_click.

1. 3. Depois de digitar o título, o campo cresce e empurra a descrição para

baixo — nunca clicar na descrição por coordenada guardada de antes.

1. 4. Conferir o cabeçalho do diálogo depois de salvar, não depois de digitar.

Se ainda mostrar o nome do arquivo, não pegou.

1. 5. Editar pela URL /edit do vídeo, que abre a tela de detalhes direto, sem

caçar a linha na tabela — e esperar 7 segundos depois de abrir, porque a tela aceita clique antes de estar montada.

Com isso, o vídeo seguinte (sussurro_02) foi agendado com título, descrição, classificação e horário corretos — zero retrabalho. Depois dele, konvertx_slides_v2 e cyberdropx_slides_v2 também.

A armadilha que sobrou

Uma coisa continuou dando errado mesmo com a receita estável: o clique na aba "Visibilidade". A coordenada resolvida para ela cai, às vezes, em cima do player de preview — que abre em tela cheia e fecha o diálogo, levando junto o que não tinha sido salvo. Aconteceu três vezes.

A alternativa é feia e funciona: clicar "Avançar" no rodapé, três vezes, em vez de pular direto para a aba. O rodapé nunca fica por cima do player. Trocamos um atalho de três cliques por três cliques a mais, de propósito.

O custo, em número

No começo, cada vídeo consumia cerca de 25 interações de navegador. Com a receita estável — esperar a verificação, limpar do jeito certo, "Avançar" no rodapé — caiu para cerca de 10.

Para os 35 vídeos que faltavam depois do primeiro lote, a diferença é entre ~875 e ~350 interações. Nenhum dos dois números é bom. Viável, lento e frágil — as três palavras juntas descrevem exatamente o tipo de tarefa que deveria ser API e não navegador.

A YouTube Data API v3 faz upload, título, descrição, tags, classificação e agendamento num script, com um OAuth de uso único. A decisão de continuar no navegador foi tomada quando "só faltavam alguns vídeos". Nunca são alguns vídeos.

Um detalhe secundário que também custou

Dois vídeos ficaram agendados para 00:00 em vez de 18:00, porque o campo de hora foi preenchido antes de o expander do agendador terminar de abrir. Não impede a publicação — só publica no pior horário possível para conteúdo curto.

A ordem correta, que parece burocracia e não é:

1. 1. abrir o expander "Programar como público" e esperar 3 segundos
2. 2. só então triple_click no campo de hora e digitar
3. 3. clicar na seta do seletor de data, não no texto
4. 4. clicar no dia
5. 5. clicar em "Programar" — se a verificação ainda estiver rodando, o clique é

engolido em silêncio; esperar e clicar de novo

O passo 5 é o mesmo bug do formulário, vestido de outra roupa: a interface aceita a ação antes de estar pronta para executá-la, e não avisa.

---

Na parte 2 desta série, o mesmo problema aparece em seis plataformas diferentes, com um disfarce novo em cada uma — e a regra que finalmente resolveu.

Perguntas frequentes

Por que não usar a YouTube Data API em vez de automatizar o Studio?

Porque é a decisão certa e a gente demorou a tomar. A API v3 resolve upload, título, descrição, tags, classificação e agendamento num script — o equivalente a ~875 interações de navegador vira alguns minutos. O motivo de termos começado pelo navegador foi que já havia sessão logada e parecia mais rápido para 'só alguns vídeos'. Não eram alguns vídeos.

`ctrl+a` funciona em campo contenteditable?

Não de forma útil. A seleção acontece no DOM, mas o React do YouTube Studio não a registra como mudança de estado: o texto digitado se soma ao anterior em vez de substituí-lo, e o Studio descarta o resultado. `triple_click` também não resolve — seleciona só uma linha, e título longo quebra em duas. A única sequência que funcionou em todos os casos foi `ctrl+End`, `ctrl+shift+Home`, `Delete` e então digitar.

Por que o `Delete` extra, se digitar sobre uma seleção já substitui?

Deveria substituir. Nesse campo, às vezes sobra um caractere da seleção anterior. Foi assim que um vídeo foi ao ar com o título `IIA corrigindo`. O `Delete` custa uma tecla e elimina a classe inteira de erro.

Como saber que o formulário está estável antes de digitar?

No YouTube Studio, o rodapé do diálogo mostra 'Verificação X% — N minutos restantes' enquanto o vídeo processa. Só digitar depois de 'Verificações concluídas'. É a única sinalização confiável; o formulário aparece preenchível muito antes de estar.