(Wahrscheinlich seit dem Update auf 2.5.0 Stable) werden sichere Mediendateien (Audio) auf Safari beim ersten Klick nicht abgespielt. Es sind zwei oder drei Klicks auf das Wiedergabesymbol erforderlich, um das Audio zu starten. Bei den ersten Klicks wird keine Anfrage an den Webserver gesendet. Erst der dritte Klick oder so sendet die Anfrage.
Das scheint ein Browserproblem zu sein, da es nur auf Safari auftritt, aber es wirkt etwas verdächtig, dass dies genau mit dem Update auf 2.5.0 begann.
Ich werde mir das morgen ansehen. Wenn es dort zwei oder drei Klicks braucht, klingt das nach einem Safari-Problem – ich werde es auf meinem iPhone ausprobieren.
Ich kann bestätigen, dass dies auf iOS sowohl mit Safari als auch mit Firefox fehlerhaft ist. Die Audio-Wiedergabe startet erst, nachdem mehrfach zwischen Wiedergabe und Pause gewechselt wurde. Das Widget-Komponente sieht in beiden Fällen gleich aus (ich glaube, dass Firefox Mobile lediglich eine Hülle um die mobile Safari-Rendering-Engine ist). Ich habe dies unter iOS 13.5.1 getestet.
Dieser W3Schools-Audio-Clip funktioniert bei mir sowohl in iOS Safari als auch in Firefox: W3Schools Tryit Editor. Möglicherweise liegt das Problem daran, dass wir preload="none" verwenden? Das ist der einzige Unterschied, an den ich denken kann … oder dass unsere 302-Umleitung der sicheren Medien-URL auf die eigentliche Audio-URL ein Problem verursacht?
Einige mögliche Hinweise, die mich zu der Annahme verleiten, dass die Umleitung das Problem ist:
Das ist leider nicht der Fall, ich war mit anderen Projekten beschäftigt. Es steht jedoch auf meiner Liste, und ich hoffe, dass ich mich bald eingehender damit befassen kann. Wir haben solche Probleme auch intern bereits kurz besprochen.
Bisher war das ein Abenteuer… Ich habe es geschafft, das Remote-Debugging zwischen Chrome auf meinem Ubuntu-Rechner und iOS Safari auf meinem iPhone einzurichten, was mit vielen Schwierigkeiten verbunden war. Allerdings ist der Reiter „Network
Das hat mich dazu inspiriert, mitmproxy einzurichten und mir erneut anzusehen, was hier vor sich geht. Es scheint, als würde die erste “Fertig”-Anfrage das iOS-Gerät bzw. den Safari-Browser nicht verlassen. Der mitm-Proxy registriert nichts, bis das zweite Mal auf PLAY geklickt wird.
Wäre es sinnvoll, preload="metadata" nur für Safari zu verwenden (sowohl iOS als auch Desktop; ich kann dies auch auf dem Desktop reproduzieren) und preload="none" ansonsten?
(Außerdem scheint dies bei Android bei mir nicht aufzutreten, getestet in einer PWA.)
Ja, ich denke, wir müssen diesen Weg gehen. Danke, dass du auch auf Android und Desktop-Safari getestet hast. Das preload-Attribut funktioniert derzeit nicht, also müssen wir wahrscheinlich Client-seitigen Code schreiben, der erkennt, ob der Browser Safari ist, und das preload-Attribut entsprechend ändert. Ich werde heute einige Experimente damit durchführen.
Um sicherzugehen, dass ich das richtig verstehe: Der Fehler tritt bei Audio wieder auf, wenn Safari einen Download-Chunk-Punkt nach der 5-Minuten-Marke setzt?
Ja, aber mit diesem neuen Fix glaube ich, dass ich das umgehen kann, indem ich das preload-Attribut nur ändere, wenn der Beitrag mit dem Medieninhalt in den Sichtbereich kommt (z. B. durch Scrollen). Das Problem ist, dass sobald die Metadaten von der sicheren Medien-URL abgerufen werden, die signierte URL generiert und im Player verwendet wird, die nach 5 Minuten abläuft. Wenn du also innerhalb dieser 5 Minuten nicht auf „Abspielen
Mit @martinwoodwards Segen habe ich heute einige Commits durchgeführt, die dazu führen, dass preload="metadata" für alle Audio-/Video-Elemente in allen Kontexten verwendet wird, einschließlich gesicherter Medien. Dies sollte das hier beschriebene Problem beheben.
Bitte beachten Sie: Wenn der Benutzer länger als 5 Minuten auf der Seite bleibt, kann es sehr wahrscheinlich sein, dass er die Audio- oder Videodateien nicht mehr abspielen kann, da die gesicherten URLs derzeit nur 5 Minuten gültig sind.
