Também é interessante que, com o console de desenvolvedor do Chrome aberto, a versão original funcione após uma atualização:
Primeira carga no Chrome:
Conteúdo misto: A página em ‘How to embed WebM’ foi carregada via HTTPS, mas solicitou um elemento inseguro ‘http://s1.webmshare.com/jvY0A.webm’. Esta solicitação foi automaticamente atualizada para HTTPS. Para mais informações, veja Chromium Blog: No More Mixed Messages About HTTPS
Falha ao carregar o recurso: o servidor respondeu com status 404 () s1.webmshare.com/jvY0A.webm:1
Atualização no Chrome (surpreendente que funcione agora — imagino que as configurações de segurança estejam mais relaxadas com as ferramentas de desenvolvedor abertas):
Conteúdo misto: A página em ‘How to embed WebM’ foi carregada via HTTPS, mas solicitou um elemento inseguro ‘http://s1.webmshare.com/jvY0A.webm’. Esta solicitação foi automaticamente atualizada para HTTPS. Para mais informações, veja Chromium Blog: No More Mixed Messages About HTTPS
Os erros são ligeiramente diferentes no Firefox, e ele continua falhando ao carregar após a atualização com o console de desenvolvedor aberto. Esse comportamento consistente parece mais razoável:
Carregando conteúdo de exibição misto (inseguro) “http://s1.webmshare.com/jvY0A.webm” em uma página segura
Falha ao carregar ‘http://s1.webmshare.com/jvY0A.webm’. Um ServiceWorker passou uma promessa para FetchEvent.respondWith() que foi rejeitada com ‘Error: no-response :: [{“url”:“http://s1.webmshare.com/jvY0A.webm”}]’.
Todos os recursos candidatos falharam ao carregar. Carregamento de mídia pausado.
Parece ser um problema de http versus https. Com o link original (sem prefixo), parece que o padrão é http://. Aqui está outra versão que inclui explicitamente o prefixo seguro https://, mas também não está funcionando.
https://s1.webmshare.com/jvY0A.webm
Parece ser um problema com o host webmshare, onde sua conexão https não é realmente segura.
É um pouco irritante que Chrome, Firefox e DDG lidem com esse problema de maneiras diferentes.
