Hi.
The latest update to iOS 14.4, I don't know why or how, just broke my iframes. They just don't work on 14.4 (tested both on Safari and Chrome), but they work fine on iOS 14.3 or any other platform. I guess this has to do with the two bugfixes WebKit implemented, but this feels pretty weird.
Actually, the bug only happens when using iframes with videos. The videos become black and not playable.
But, not all iframes. Only some, but I can't understand what are the factors which influence this.
I can only tell that any iframe I create dynamically using JS works except for MY own iframes coming from private servers. External iframes video players like Streamtape's or other streaming websites do work fine, but my own iframes loading my own mp4 files do not work. I mean, any iframe manually generated by me - by that I mean a simple iframe which literally uses this simple HTML:
Yeah, that's as simple. But it doesn't work, the video doesn't load, the screen keeps black with 00:00 of length of the video and there's no error in console at all (tried debugging).
But, when using external URLs, like Streamtape's player, all works fine. Only my own iframes don't.
The error is not traceable to my mp4 files, because, as I said, they work fine on any platform except iOS 14.4.
Is there anything I miss? Maybe on server-side? Should there be some HTTP headers that tells "this content is secure"?
I don't know what to do, this bug seems untraceable and just happens with the latest version of iOS.
The latest update to iOS 14.4, I don't know why or how, just broke my iframes. They just don't work on 14.4 (tested both on Safari and Chrome), but they work fine on iOS 14.3 or any other platform. I guess this has to do with the two bugfixes WebKit implemented, but this feels pretty weird.
Actually, the bug only happens when using iframes with videos. The videos become black and not playable.
But, not all iframes. Only some, but I can't understand what are the factors which influence this.
I can only tell that any iframe I create dynamically using JS works except for MY own iframes coming from private servers. External iframes video players like Streamtape's or other streaming websites do work fine, but my own iframes loading my own mp4 files do not work. I mean, any iframe manually generated by me - by that I mean a simple iframe which literally uses this simple HTML:
Code Block html <!DOCTYPE html> <html lang="it"> <body> <video controls> <source src="https://blahblah.mp4" type="video/mp4"> </video> </body> </html>
Yeah, that's as simple. But it doesn't work, the video doesn't load, the screen keeps black with 00:00 of length of the video and there's no error in console at all (tried debugging).
But, when using external URLs, like Streamtape's player, all works fine. Only my own iframes don't.
The error is not traceable to my mp4 files, because, as I said, they work fine on any platform except iOS 14.4.
Is there anything I miss? Maybe on server-side? Should there be some HTTP headers that tells "this content is secure"?
I don't know what to do, this bug seems untraceable and just happens with the latest version of iOS.
In the end, it resulted to be a bug related to how CORS behaves in service workers in Safari.
I'll explain if someone will need it in the future.
I can't exactly understand what happened properly, I can only tell that it depended from a service worker which listened to fetch events and responded with fetched data.
That data fetching threw an error if the CORS headers were not specified, even if by default in other environments the CORS works.
Basically, I solved it by removing the service worker which listened to the fetch event, because we did not need it anymore, but most likely you can solve by putting CORS headers or you can try playing out with the service worker respondWith method and see what you can do.
I'll explain if someone will need it in the future.
I can't exactly understand what happened properly, I can only tell that it depended from a service worker which listened to fetch events and responded with fetched data.
That data fetching threw an error if the CORS headers were not specified, even if by default in other environments the CORS works.
Basically, I solved it by removing the service worker which listened to the fetch event, because we did not need it anymore, but most likely you can solve by putting CORS headers or you can try playing out with the service worker respondWith method and see what you can do.
