(Probablemente desde la actualización a la versión estable 2.5.0) los archivos de audio de medios seguros no se reproducen en Safari al primer clic. Se requieren dos o tres clics en el icono de reproducción para iniciar el audio. En los primeros clics, no se recibe ninguna solicitud en el servidor web. Solo el tercer clic, aproximadamente, envía la solicitud.
Esto parece ser un problema del navegador, ya que solo ocurre en Safari, pero resulta un poco sospechoso que haya comenzado a suceder alrededor de la actualización a la versión 2.5.0.
Puedo confirmar que esto presenta errores en iOS, tanto con Safari como con Firefox. El audio no se reproduce hasta que se realizan múltiples acciones de reproducir/pausar. El componente del widget se ve igual en ambos (creo que Firefox móvil es simplemente un contenedor del motor de renderizado de Safari móvil). Probé esto en iOS 13.5.1.
Este fragmento de audio de w3schools sí funciona para mí en iOS Safari y Firefox: W3Schools Tryit Editor. Posiblemente el problema sea que usamos preload="none". Esa es la única diferencia que se me ocurre… o que nuestra redirección 302 de la URL de medios segura a la URL de audio real cause algún problema.
Algunas pistas posibles que me llevan a pensar que es la redirección la que causa el problema:
Desafortunadamente no, he estado ocupado con otros proyectos. Sin embargo, tengo esto en mi lista y espero comenzar a revisarlo más a fondo pronto. También hemos discutido brevemente problemas similares internamente.
Hasta ahora, esto ha sido una aventura… logré configurar la depuración remota entre Chrome en mi máquina Ubuntu y Safari en iOS en mi iPhone, aunque con muchos tropiezos. Sin embargo, lo molesto es que la pestaña de Red (Network) aparece en blanco, y esa es, en cierto modo, la más importante para este caso.
He descubierto que establecer preload="metadata" hace que el audio se reproduzca al primer clic en Safari en iOS, mientras que si se configura como preload="none", se requiere una secuencia de Reproducir > Pausar > Reproducir para que el audio realmente se reproduzca.
Probé esto con video y parece que existe un problema similar.
Sigo pensando en esto y probando cosas… No estoy seguro de si podemos tener lo mejor de ambos mundos aquí. No es una experiencia ideal que los medios seguros requieran múltiples clics para verse.
Edición: Logré que la pestaña de Red de mi depurador funcione. Un ejemplo en nuestra instancia interna de Discourse para una etiqueta audio con preload="none":
Presiona Reproducir: GET /secure-media-uploads/dev/original/4X/6/1/8/618a6b19a07de18205cc9889cb604e414b30372b.mp3, que devuelve un estado de Finished.
Presiona Pausa.
Presiona Reproducir: GET presigned_url_here, que devuelve un estado de 206 Partial Content, y el audio se carga correctamente.
Lo extraño aquí es que con preload=“metadata” obtenemos exactamente la misma secuencia de solicitudes, pero con un solo clic en Reproducir. Es como si Safari obtuviera los metadatos al primer clic en Reproducir y luego necesitara una pausa y volver a reproducir para que el audio suene.
No estoy seguro de si esto ocurre en otros dispositivos, por ejemplo, en Android. No tengo un dispositivo para probarlo allí.
Esto me inspiró a configurar mitmproxy y volver a examinar qué está ocurriendo aquí. Parece que la primera solicitud “Finalizada” no sale del dispositivo iOS / navegador Safari. El proxy mitm no registra nada hasta que se hace clic en PLAY por segunda vez.
¿Tendría sentido usar preload="metadata" solo para Safari (tanto en iOS como en escritorio; puedo reproducir esto en escritorio también) y preload="none" en el resto?
(También, esto no parece estar ocurriendo en Android para mí, lo probé en una PWA.)
Sí, creo que tendremos que tomar ese camino. Gracias por probar también en Android y Safari de escritorio. El atributo preload está deshabilitado en este momento, así que supongo que necesitaríamos algún código del lado del cliente para detectar que el navegador es Safari y cambiar el atributo preload. Haré algunas pruebas con esto hoy.
Para asegurarme de que lo entiendo correctamente, ¿el error volverá a aparecer en el audio cuando Safari cree un punto de fragmentación de descarga después del límite de 5 minutos?
Sí, pero con esta nueva corrección creo que puedo solucionarlo cambiando el atributo preload solo cuando el post con el multimedia entra en la vista (por ejemplo, al hacer scroll). El problema es que, una vez que se obtienen los metadatos de la URL segura del multimedia, se genera una URL firmada que se usa en el reproductor y que caduca en 5 minutos. Por lo tanto, si no pulsas reproducir en esos 5 minutos, la URL habrá caducado.
Me pregunto si puedo usar JavaScript para reproducir y luego pausar el multimedia, y si eso afecta a las solicitudes de contenido parcial 206 que se envían después, las cuales parecen no estar sujetas a la caducidad de la URL firmada. Aunque podría estar equivocado, necesito probar más.
Edición: He confirmado en un dispositivo Android usando Chrome que este problema no existe allí.
Con el consentimiento de @martinwoodward, hoy realicé algunos commits que cambian el uso a preload="metadata" para todos los elementos de audio y video en todos los contextos, incluidos los medios seguros. Esto debería solucionar el problema descrito aquí.
Ten en cuenta que si el usuario permanece en la página durante más de 5 minutos, es muy probable que no pueda reproducir el audio o el video, ya que las URL seguras actualmente solo son válidas durante 5 minutos.
