(Probabilmente a partire dall’aggiornamento alla versione 2.5.0 stabile) i file audio multimediali protetti non vengono riprodotti su Safari al primo clic. Sono necessari due o tre clic sull’icona di riproduzione per avviare l’audio. Nei primi clic, non viene ricevuta alcuna richiesta sul server web. Solo il terzo clic circa invia la richiesta.
Sembra un problema del browser, dato che si verifica solo su Safari, ma è un po’ sospetto che ciò sia iniziato con l’aggiornamento alla 2.5.0.
Posso confermare che su iOS il problema si presenta sia con Safari che con Firefox. L’audio non viene riprodotto finché non si eseguono più volte le azioni di play/pausa. Il componente widget appare identico in entrambi i browser (credo che Firefox mobile sia semplicemente un wrapper sul motore di rendering di Safari mobile). Ho testato su iOS 13.5.1.
Questo clip audio di w3schools funziona correttamente su Safari e Firefox per iOS: W3Schools Tryit Editor. Forse il problema è l’uso di preload="none"? È l’unica differenza che riesco a pensare… oppure potrebbe essere causato dal reindirizzamento 302 dell’URL multimediale sicuro verso l’URL effettivo dell’audio?
Alcuni indizi che mi portano a pensare che il problema sia il reindirizzamento:
Purtroppo no, sono stato impegnato su altri progetti. Ho questo nella mia lista, comunque, e spero di iniziare a esaminarlo più approfonditamente presto. Abbiamo anche discusso brevemente di questioni simili internamente.
Finora è stata un’avventura… sono riuscito a configurare il debug remoto tra Chrome sulla mia macchina Ubuntu e Safari iOS sul mio iPhone, con molte difficoltà. Tuttavia, in modo fastidioso, la scheda Rete è vuota, il che è piuttosto la più importante in questo caso.
Ho scoperto che impostare preload="metadata" fa sì che l’audio venga riprodotto al primo clic in Safari iOS, mentre se è impostato su preload="none" è necessaria una sequenza di Riproduci > Pausa > Riproduci per far partire effettivamente l’audio.
Ho provato anche con il tag video e sembra che esista un problema simile.
Sto ancora riflettendo e sperimentando… non sono sicuro che possiamo avere il meglio da entrambi i mondi. Non è un’esperienza ideale per i media sicuri richiedere più clic per essere visualizzati.
Modifica: sono riuscito a far funzionare la scheda Rete del mio debugger. Un esempio sulla nostra istanza interna di Discourse per un tag audio con preload="none":
Premi Riproduci: GET /secure-media-uploads/dev/original/4X/6/1/8/618a6b19a07de18205cc9889cb604e414b30372b.mp3 che restituisce uno stato di Completato
Premi Pausa.
Premi Riproduci: GET presigned_url_here che restituisce uno stato di 206 Partial Content, e l’audio viene caricato correttamente.
La cosa strana è che con preload=“metadata” otteniamo esattamente la stessa sequenza di richieste, ma con un solo clic su Riproduci. È come se Safari recuperasse i metadati al primo clic su Riproduci, per poi aver bisogno di una pausa e di un nuovo clic su Riproduci per far partire l’audio.
Non sono sicuro che questo accada anche su altri dispositivi, ad esempio Android? Non ho un dispositivo con cui fare test lì.
Questo mi ha ispirato a configurare mitmproxy e a dare un’altra occhiata a cosa sta succedendo qui. Sembra che la prima richiesta “Completata” non stia uscendo dal dispositivo iOS / dal browser Safari. Il proxy mitm non registra nulla fino al secondo clic su PLAY.
Sì, penso che dovremo prendere quella strada. Grazie per aver testato anche su Android e Safari Desktop. L’attributo preload non funziona al momento, quindi immagino che avremo bisogno di un codice lato client per rilevare se il browser è Safari e sostituire l’attributo preload. Farò alcune prove con questo oggi.
Per assicurarmi di aver capito correttamente, il bug si ripresenterà negli audio in cui Safari crea un punto di frammentazione del download oltre il limite dei 5 minuti?
Sì, ma con questa nuova correzione penso di poter aggirare il problema modificando l’attributo preload solo quando il post con i media entra nella visuale (ad esempio tramite lo scorrimento). Il problema è che una volta recuperati i metadati dall’URL dei media sicuro, viene generato l’URL firmato e utilizzato nel player, che scade dopo 5 minuti. Quindi, se non si preme play entro quei 5 minuti, l’URL sarà scaduto.
Mi chiedo se sia possibile utilizzare JS per riprodurre e poi mettere in pausa i media, e se questo faccia una differenza per le richieste di contenuto parziale 206 inviate successivamente, che non sembrano essere soggette alla scadenza dell’URL firmato. Potrei anche sbagliarmi, devo fare ulteriori test.
Modifica: Ho confermato personalmente su un dispositivo Android con Chrome che questo problema non esiste lì.
Con il benestare di @martinwoodward, oggi ho effettuato alcune modifiche per utilizzare preload="metadata" per tutti gli elementi audio/video in tutti i contesti, inclusi i media protetti. Questo dovrebbe risolvere il problema descritto qui.
Tieni presente che se l’utente rimane sulla pagina per più di 5 minuti, probabilmente non potrà riprodurre l’audio o il video, poiché gli URL sicuri sono attualmente validi solo per 5 minuti.
