I have a site with an embedded YouTube Flash (AS3) player, and it's no longer working in Safari.
Check out this fiddle, the code for which is merely:
<object type="application/x-shockwave-flash"
data="http://www.youtube.com/apiplayer">
</object>
In Chrome, Firefox, and IE, the request to http://www.youtube.com/apiplayer returns normally (200). In Safari, the server returns a 303 to https://youtube.googleapis.com/apiplayer.
This player loads, but I am unable to interact with it in JavaScript. I assume that's because it's served over https — though I am explicitly requesting http — resulting in a mixed-mode security issue. Here's error I see when trying to do anything with the player (this is with the full chromeless player embed code):
>>> player.playVideo()
Error: Error calling method on NPObject.
If I change Safari's user agent to something else, or even just mangle the word "Safari", then the correct player is loaded. I also have no trouble loading the Vimeo and Viddler players (http://vimeo.com/moogaloop.swf and http://www.viddler.com/player/key).
I see this both in the stable Safari release and in the WebKit nightly. It also occurs with my extensions disabled and in Private Browsing mode.
I tried working around it by embedding http://youtube.googleapis.com, hoping that there would be no redirect and I'd get the player over http. But it still redirects to https, and it does so in all browsers.
I filed this YouTube API ticket last week, but there's been no response so far.
Seems like there's a playback issue with Safari and YouTube. There're multiple solutions suggested at MacRumours http://forums.macrumors.com/showthread.php?t=1098606, like switching to 32 bit browser, use non-HTML5 version, etc.
One that seems to work is below:
Select Safari > Preference > Privacy > Details
Search for Youtube
Delete the cookie called youtube-nocookie.com then click Done.
Restart Safari and try again.
The YT API bug report has been answered, and there is a workaround: appending the version to the URL:
<object type="application/x-shockwave-flash"
data="http://www.youtube.com/apiplayer?version=3">
</object>
Apparently when the version is not specified, they fall back to the AS2 player for Safari only. I'm not sure why that would force the switch to https, but regardless, this works.
Related
I am trying to display a TVHeadend stream in the browser as a pre-cursor to get this running on my TV. So I whipped up this sample HTML code where 192.168.0.4 is my server running TVHeadend and the channel UUID is 3df2b09783d8afeb8a323f5025431df7:
<html>
<body>
<video width="720" height="567" autoplay="true" controls>
<source src="http://192.168.0.4:9981/stream/channel/3df2b09783d8afeb8a323f5025431df7?profile=webtv-h264-aac-matroska" type="video/webm">
Your browser does not support the video tag.
</video>
</body>
</html>
Whether I show the HTML page locally on my computer or served via a local Apache webserver, the result is always the same: I get an emtpy video player control. The network tab does not show any errors, neither does the console. It does bring a warning however:
"Empty src!"
However the src is clearly not empty.
When I copy the src URL to my browser (Chrome) and call it, it starts downloading the stream (instead of showing it, but that might be expected). Why does the video control not seem to be able to show the video?
Do I have any other debug options I can check out? This problem has bugged me for a while now and I have tried to drill down to the source of it by removing the TV SDK and all other side code just to see if the actual video will play (which it does not).
At first I thought it might've been an authorization issue but then why does Chrome seem to be able to download the stream just fine? I have logged on to TVHeadend in the same browser (in a different tab) to make sure that a missing logon is not in the way of things.
I have also tried putting : in between the "http://" and the IP address to pass the parameters required for basic auth - but to no avail.
Does somebody have any hints as to what might be the roadblock here?
Here is the link to the bigcommerce store I'm working on. It shows background video on all the devices except IOS devices on any browser.
https://axict.mybigcommerce.com/
Looking for help in this weird issue.
Thanks in advance.
Here is the video element code,
<video id="bannerVideo" class="bgVideovideo" autoplay loop muted playsinline>
<source src="https://store-1anxrygvum.mybigcommerce.com/content/banner-video.webm"
type='video/webm;codecs="vp8, vorbis"' />
<source src="https://store-1anxrygvum.mybigcommerce.com/content/banner-video.mp4"
type='video/mp4;codecs="avc1.42E01E, mp4a.40.2"' />
Your browser does not support the video tag.
</video>
From a quick check this actually does not work on Safari on MacOS either and it does on Chrome on the same Mac.
Looking at the network traffic you can see the server responds with a '200' to the byte range request from the browser for the video, which Safari does not handle well, although Chrome does:
The most common root cause of this issue appears to be servers that are not configured to handle range requests in what Safari consider the correct manner. It expects to see a '206' response when it sends a request with a byte range.
There is more discussion and examples in the answer here: https://stackoverflow.com/a/32998689/334402
Looks like you've uploaded the video to WebDAV - just like Mick's answer, the file hosting server that BigCommerce WebDAV uses is not configured to send the correct request type that IOS/Safari is looking for when loading a <video> element's source.
When I ran into this, I had to upload the video to AWS S3 Storage. You should be able to get 5GB permanently on the free tier.
My predecessor at my workplace built a website (mahlerclean.com) for a client that allows job applicants to log onto another site (joblinkapply.com) via an iframe. The client has recently gotten complaints from applicants who are not able to log into the site via the iframe.
I am able to reproduce the issue in Safari. When I go to https://www.mahlerclean.com/career-center/job-openings it does not let me log into https://www.joblinkapply.com/company/6435 from there, and I see this message in the Safari web console:
Blocked a frame with origin "https://www.joblinkapply.com" from accessing a frame with origin "https://www.mahlerclean.com". Protocols, domains, and ports must match.
I have not been able to reproduce the issue in Firefox or Chrome though, and of course, if you navigate directly to https://www.joblinkapply.com/company/6435 (rather than through the iframe), it works fine in all browsers.
I control mahlerclean.com, but do not have any control over joblinkapply.com
My questions are:
Is there anything I can do to the site at mahlerclean.com that would
allow the iframe to joblinkapply.com to work on all browsers?
Why am I only seeing the issue in Safari? Are the other browsers likely to get more strict (i.e. behave like Safari) in the future?
Is it even reasonable to try to support logins to a remote site through an iframe, or should I tell the client to ditch the iframe, and just link out to https://www.joblinkapply.com/company/6435?
The title pretty say it all, a fully fonctional video.js player broke on safari for mac after moving the video on a distant media server. It works on chrome, firefox and IEs.
my first guess is a cross server issue, but it shoudln't work on others browsers if it was the case.
When I visit the Spotify Play Button demo page (https://developer.spotify.com/technologies/spotify-play-button/) in Opera 11.62, clicking on the Play Button gives me the (mostly-expected) popup:
The application "Spotify" must be launched to open the link:
spotify:
Do you want to proceed?
If I click yes, the Spotify app then launches (if not already running) and gets focus, but does not play anything. I suspect the link is getting broken by Opera somehow (notice that it has the spotify: protocol name but nothing after that). The Play Button on my own site produces the same behavior. Works fine in Firefox on the same machine.
Has anyone else experienced this?
Yes, sadly, that's the case. There's a similar issue in Opera's bug tracker.
I think your particular issue could be related to Opera's lack of support for cross-origin resource sharing (CORS). CORS support is coming is available in Opera Next, but not Opera 11.62. If it doesn't work in Next, I encourage you to file a bug report.