Player clips do not display in Mac Safari 16.0 when Requestly Desktop App enabled (even without any Requestly rules enabled)

When page is loaded in Mac Safari 16.0 without Requestly Desktop app opened it displays the clip (as expected)

When page is loaded in Mac Safari 16.0 with Requestly Desktop app opened it displays a black object instead of the player (even when no Requestly rules are enabled)

BTW - This issue occurs on several different pages that contain our player.

@Sachin @rq_admin Kindly advise how to overcome this urgent issue.

@nsrCodes Can you please have a look at this issue?

@Sagi_Kolodaro Is this only happening in Safari 16? Do you know if it was also happening in previous Safari versions too?

@Sachin I only noticed this issue occurring after I upgraded to Safari 16 last week. In previous Safari versions, I never experienced this specific issue occurring.

@Sagi_Kolodaro I tried to reproduce this issue but everything seems to work as expected. I do see the blank image that you mentioned during the initial few seconds of page load, but that too goes away.
Could it just be a slow internet connection?
Does the page load well in other browsers with/without Requestly?

going through safari 16’s release notes the only thing that sort of felt relevant was this

Added support for non-animated AVIF.

@Sagi_Kolodaro There have been some recently reported issues around the rendering of avif streams. I see that the container for the media files here is gif and not avif but couldn’t confirm what was the type of the video stream.

Just wanted more info to confirm that the proxy isn’t messing up the received data stream.

@nsrCodes I retested once again today on Mac Safari 16.0 and the issue still occurs whenever the Requestly desktop app is enabled (with/without the Requestly rules enabled) and as a result, the player displays only as a black rectangle on the page (no matter how long I wait). As soon as I close the Requestly desktop app the clips immediately begin to play on the player. If I reopen the Requestly desktop app and refresh the same browser page then once again the black rectangle appears permanently. Whenever the black rectangle appears I verify via that I receive the ‘Success’ message.

@nsrCodes When the player first appears on the page is displays a .jpg file once it starts playing it streams the .m3u8 hls file in Mac Safari/iOS otherwise it streams the .mp4 file in all other desktop browsers in Windows and Android

@Sagi_Kolodaro Thank you so much for being patient.
Since I wasn’t able to reproduce the exact issue myself I tried to work on the information that you provided about the player using an hls stream in this case.
Each segment of an hls stream is a an arbitrary binary stream which is returned with a content type of applicatoin/octet-stream . We have had many similar, hard to reproduce, bugs in the past related to octet streams
We are working on fixing this but in the meantime here are a few suggestions to help you get things working for now

  1. Since the hls stream is the problem, we can trick the player into believing that we are on windows and make it use the mp4 stream instead. This can be done using the user agent rule and setting it to something like Windows tablet. After the rule is applied, the network tab shows no calls to the m3u8 stream

Here is a template rule that you can further modify for the different sites that you use (or maybe even directly point it to your cdn endpoint)

  1. We have recently fixed a similar issue issue for google meet by adding it to the bypass list of OSX’s system proxy settings. this way the requests for never went through Requestly. For now you can follow these instructions to add either or to your system’s bypass list.

You can also choose to bypass proxy settings for specific computers on the internet (hosts) and segments of the internet (domains) by adding the address of the host or domain in the “Bypass proxy settings for these Hosts & Domains” field

I was able to reproduce a similar error on hls-demo player. In my case the site was not loading at all. Setting up the bypass list helped me solve it for now

Note: We are also working on providing an easy way to update this system bypasslist from within the Requestly app. If this works well for you, we would love to get your feedback on how you think we should implement it to make it easy to use.


Hey @Sagi_Kolodaro – Did you get a chance to try this out?