[lucastaonline]

Correções dos bugs que o desenvolvedor achou na versão publicada (https://monkyweb.vercel.app), com a causa raiz de cada um investigada antes.

1. Edge publica tela no SFU e "ninguém consegue assistir" (o mais grave)

• Causa: quem assistia era o receptor nativo do desktop (Cabulense). O Chrome e o Edge usam o encoder por software (OpenH264) quando não há encoder de hardware livre. Era o caso: o mesmo PC já transmitia a própria tela pelo encoder AMD. O OpenH264 gera H.264 Constrained Baseline (42 c0 .., com constraint_set1) mesmo com o SDP negociando Main. O receptor nativo (ValidateSps no Windows, e a mesma regra no macOS com VideoToolbox) exigia profile_idc 77 e descartava todo quadro. Resultado: PLI atrás de PLI, 0 quadros decodificados e o "carregando para sempre".
• Como confirmei: reproduzi contra um SFU de verdade (servidor descartável na VM, mídia direto no IP público), com o Edge publicando e o desktop assistindo pelo receptor nativo. Com o encoder de hardware, funciona. Com --disable-accelerated-video-encode (OpenH264), framesDecoded = 0. Também li o SPS real dos dois encoders.
• Correção: pela norma H.264 (A.2.1), constraint_set1 = 1 declara que o bitstream respeita o perfil Main, então um receptor Main deve aceitá-lo. A regra fica num lugar só (DecodesAsH264Profile, em h264_bitstream) e vale para Windows e macOS. Baseline sem constraint_set1 continua recusado.
• Teste: dois casos novos no probe de contratos nativos (adapter_policy_probe.cc), que roda no build nativo do CI.
• Limite: como a correção está no receptor, quem assiste precisa estar no desktop desta versão ou mais nova.

2. Firefox e Safari: o botão de compartilhar tela ficava liberado e não funcionava

• Causa: duas regras para a mesma coisa. A capability screenShare da web só olhava se o getDisplayMedia existe, enquanto o runtime de tela também exige encoder H.264 Main. O Firefox (OpenH264) e o Safari (VideoToolbox) só oferecem Constrained Baseline/High no WebRTC.
• Correção: a capability usa o webScreenCapabilities() do próprio runtime. O botão fica travado pela regra central, com o motivo na dica e no aviso: "Este navegador não transmite tela no formato do Monky (H.264). Use o Chrome ou o Edge, ou o app desktop."

3. Firefox e Safari: assistir tela

• H.264: nenhum dos dois recebe H.264 Main pelo WebRTC. A mensagem antiga mandava pedir H.264, o que se contradiz. Agora diz que este navegador não recebe telas em H.264 e indica Chrome, Edge ou o app.
• AV1 (o caso do desenvolvedor): o Firefox aprova AV1 até 1080p60 no decodingInfo, e depois a tela nunca mostra um quadro. Ela caía no genérico "Não foi possível estabelecer ou manter esta transmissão". Agora, se o prazo do primeiro quadro termina com vídeo chegando e nada decodificado, o motivo é o decodificador ("não suportado"), e a mensagem só sugere pedir H.264 quando o navegador recebe H.264.

4. NES (miniapp do MonkyBot)

• Causa: é limitação real. O site dos miniapps é HTTPS, e o serviço de jogos do bot é http://147.15.118.243:7780/ws://…:7781. O navegador bloqueia isso como conteúdo misto antes de qualquer CSP, então afrouxar o CSP não resolve.
• Do nosso lado: o carregador do miniapp passa a avisar o app, uma vez, quando o miniapp tenta um serviço http:/ws: fora do localhost. O app mostra o motivo no feedback compartilhado. A chamada original segue igual.
• Do lado do bot: para funcionar na web, o serviço de jogos do MonkyBot precisa de HTTPS/WSS.

Safari (testado num Safari 26.6 de verdade, runner macOS do GitHub)

Funcionam:

• identidade Ed25519 (criar e assinar);
• chave AES não exportável;
• IndexedDB;
• getDisplayMedia;
• miniapp no iframe opaco.

Não existe File System Access, então soundboard e figurinhas usam o armazenamento do navegador. O H.264 do WebRTC só tem 640c1f e 42e01f, com AV1, VP8 e VP9 ao lado, por isso o Safari entra nos itens 2 e 3.

Não dá para garantir sem um Mac com pessoas: voz, câmera e áudio reais. O runner não tem dispositivos, e o Safari pede permissão por clique.

Testes

• webScreenPublisher.test.ts: capabilities do Firefox e do Chromium. A capability segue o runtime, e browserReceivesScreenCodec é testada.
• browserScreenSubscription.test.cjs: vídeo que chega e não decodifica dá "não suportado"; sem vídeo dá falha de conexão.
• webMiniapps.test.cjs (novo, já no script test): avisa http/ws uma vez por origem e ignora HTTPS e localhost.
• desktopOnlyDom.test.cjs: dica e aviso com o motivo.
• Probe nativo: os casos novos do H.264.

Cada teste novo falha sem a correção. Também passaram npm run build, ci:local --only "^docs " e test-native-ci.

Refs #858