[GOWS/send] /send/media omits imageMessage width/height → square placeholder until full media downloads

[catwolf-mkt]

Version: v0.7.2 (GOWS engine)

Summary

When sending an image via POST /send/media, the resulting imageMessage has no width/height set. Those fields are what WhatsApp uses to shape the bubble before the full media is downloaded, so the recipient sees a square-cropped placeholder (built from the inline thumbnail) until the full-resolution media finishes downloading. Only then does WhatsApp read the real dimensions from the file and re-render at the correct aspect ratio.

On heavier images / slower connections / when media auto-download is off, the square placeholder stays visible for a long time (or until the user taps to download), which looks broken for wide banners (e.g. 1600×720).

Evidence it's a message-construction gap (the dimensions are already known)

The generated JPEGThumbnail has the correct aspect ratio (72×32 for a 1600×720 source), so the server already decoded the image dimensions to build the thumbnail — it just doesn't write them into the Width/Height fields of the ImageMessage.

Returned imageMessage keys:

JPEGThumbnail, URL, caption, contextInfo, directPath,
fileEncSHA256, fileLength, fileSHA256, mediaKey, mimetype

No width, no height.

Reproduced with both base64 (inline in url) and an HTTP URL — same result (no dimensions either way).

Controlled comparison with Evolution API (Baileys) — same image

The exact same image file sent through Evolution API's POST /message/sendMedia produces an imageMessage with width: 1600, height: 720; through GOWS POST /send/media those fields are absent. Same recipient, same file — the only relevant difference in the message is the missing dimensions, and it maps 1:1 to the square-placeholder behavior.

Expected

imageMessage.Width / imageMessage.Height populated (as Baileys / Evolution API does) so the placeholder renders at the correct aspect immediately (blur → sharp, no reshape).

Actual

Square placeholder on arrival, then a "jump" to the correct horizontal aspect once the full image downloads. Most visible on WhatsApp Desktop and with large files.

Steps to reproduce

1. POST /send/media with a wide image (e.g. 1600×720), type: image.
2. Receive on another device and observe: the bubble is square while the full media downloads, then reshapes to landscape once it finishes.

Suggested fix

Populate ImageMessage.Width / ImageMessage.Height from the decoded image (the same decode already used to generate the JPEGThumbnail). whatsmeow's ImageMessage exposes Width / Height (uint32).

---

🇵🇹 / 🇧🇷 PT

Versão: v0.7.2 (engine GOWS)

Resumo

Ao enviar uma imagem via POST /send/media, o imageMessage resultante fica sem width/height. Como são esses campos que o WhatsApp usa para definir o formato da bolha antes de a media completa ser descarregada, o destinatário vê um placeholder quadrado (montado a partir da thumbnail inline) até a media em resolução completa terminar o download. Só então o WhatsApp lê as dimensões reais do ficheiro e re-renderiza no aspeto correto.

Com imagens mais pesadas / ligações lentas / download automático de media desligado, o placeholder quadrado fica visível muito tempo (ou até o utilizador tocar para descarregar), o que parece defeituoso em banners horizontais (ex.: 1600×720).

Evidência de que é falha na construção da mensagem (as dimensões já são conhecidas)

A JPEGThumbnail gerada tem o aspeto correto (72×32 para uma fonte 1600×720), ou seja o servidor já decodificou as dimensões para montar a thumbnail — apenas não as escreve nos campos Width/Height do ImageMessage.

Chaves retornadas no imageMessage: JPEGThumbnail, URL, caption, contextInfo, directPath, fileEncSHA256, fileLength, fileSHA256, mediaKey, mimetype — sem width, sem height.

Reproduzido com base64 (inline no url) E com URL HTTP — mesmo resultado.

Comparação controlada com a Evolution API (Baileys) — mesma imagem

O mesmo ficheiro de imagem enviado pela POST /message/sendMedia da Evolution API produz um imageMessage com width: 1600, height: 720; pela POST /send/media do GOWS esses campos estão ausentes. Mesmo destinatário, mesmo ficheiro — a única diferença relevante na mensagem são as dimensões em falta, e mapeia 1:1 com o comportamento do placeholder quadrado.

Esperado

imageMessage.Width / imageMessage.Height preenchidos (como o Baileys / Evolution API faz), para o placeholder renderizar já no aspeto correto (desfoca → foca, sem mudar de forma).

Atual

Placeholder quadrado ao chegar, depois "salta" para o aspeto horizontal correto assim que a media completa descarrega. Mais visível no WhatsApp Desktop e com ficheiros grandes.

Passos para reproduzir

1. POST /send/media com uma imagem horizontal (ex.: 1600×720), type: image.
2. Receber noutro dispositivo e observar: a bolha fica quadrada enquanto a media descarrega, depois muda para horizontal quando termina.

Sugestão de correção

Preencher ImageMessage.Width / Height a partir da imagem decodificada (a mesma decodificação já usada para gerar a JPEGThumbnail). O ImageMessage do whatsmeow expõe Width / Height (uint32).