Jusqu’à présent, cela a été une aventure… J’ai donc réussi à configurer le débogage à distance entre Chrome sur ma machine Ubuntu et Safari sur iOS sur mon iPhone, non sans quelques tribulations. Cependant, ce qui est agaçant, c’est que l’onglet Réseau reste vide, alors que c’est précisément le plus important dans ce contexte.
J’ai constaté que l’attribut preload="metadata" permet à l’audio de se lancer au premier clic dans Safari sur iOS, tandis que si l’attribut est défini sur preload="none", il faut enchaîner une séquence de Lecture > Pause > Lecture pour que l’audio se lance réellement.
J’ai testé cela avec la balise video et il semble qu’un problème similaire existe.
Le passage à preload="none" a été effectué en raison de votre rapport de bug ici : Secure media uploads expire. Nous nous trouvons désormais dans une sorte de zone crépusculaire agaçante : remettre preload sur metadata réintroduirait le problème mentionné ci-dessus. Nous avons récemment augmenté la durée de validité des URL signées à 5 minutes (FIX: Increase time of DOWNLOAD_URL_EXPIRES_AFTER_SECONDS to 5 minutes by martin-brennan · Pull Request #10160 · discourse/discourse · GitHub), ce qui rendra le bug initial moins problématique… mais il restera néanmoins un problème.
Je réfléchis encore à la question et je teste différentes solutions… Je ne suis pas certain que nous puissions avoir le meilleur des deux mondes ici. Ce n’est pas une expérience idéale pour les médias sécurisés d’exiger plusieurs clics pour être consultés.
Édition : J’ai réussi à faire fonctionner l’onglet Réseau de mon débogueur. Voici un exemple sur notre instance Discourse interne pour une balise audio avec preload="none" :
-
Appuyer sur Lecture : GET /secure-media-uploads/dev/original/4X/6/1/8/618a6b19a07de18205cc9889cb604e414b30372b.mp3, qui renvoie un statut Finished.
-
Appuyer sur Pause.
-
Appuyer sur Lecture : GET
presigned_url_here, qui renvoie un statut 206 Partial Content, et l’audio se charge correctement.
Ce qui est étrange ici, c’est que avec preload=“metadata”, nous obtenons exactement la même séquence de requêtes, mais avec un seul clic sur Lecture. On dirait que Safari récupère les métadonnées au premier clic sur Lecture, puis a besoin d’une pause suivie d’une nouvelle lecture pour lancer l’audio.
Je ne sais pas si ce phénomène se produit sur d’autres appareils, par exemple Android ? Je n’ai pas d’appareil pour tester dans ce cas.