Invisible SoundCloud iframes - google-chrome

On pages containing multiple SoundCloud iframes, a random subset of those iframes appear invisible in both Chrome and Firefox, and instead of containing the normal SoundCloud content they contain the following HTML. The iframes affected often change with each page load, and youtube iframes on the same page are unaffected. Does anyone know the cause and/or a workaround?
UPDATE: On further examination, this is standard SoundCloud content, except div id="widget" is empty, and a manual iframe reload on an individual iframe forces it visible. Is this maybe a situation where the iframe is first loaded, then the div content is fetched with an XHR, and on a page where the browser is laboring over numerous loads on a congested network some XHR's silently time out? If so SoundCloud, could you increase your XHR timeout?
UPDATE 2: I tested this some more on 2 separate machines on the same LAN, and it looks like it might be a problem with the current version of the standard Flash plugin (11.5.502.110 on winXP--installed by auto-update Nov.9, about when this started, and 11.2.202 on Ubuntu 12.04--installed today, Nov. 27). The following information should make it reproducible. I get 100% consistent failures in Firefox on both machines, and I can toggle the failures on and off in Chrome (on both machines) by enabling the standard plugin vs. Chrome's own PepperFlash plugin. There are 100% no failures with PepperFlash, but the current version of the PepperFlash player is unusable because of impossibly choppy audio.
<html lang="en">
<head>
<meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"> <meta name="viewport" content="width=device-width, minimum-scale=1, maximum-scale=1, user-scalable=no">
<title>SoundCloud Widget</title>
<base target="_blank">
<link rel="stylesheet" href="/player/assets/widget-22748325.css">
<script src="/player/assets/widget-ab572693.js"></script>
<script>
require(["lib/support", "lib/flash-widget"], function(support, flashWidget) {if (support.newWidget) { require(["application"], function(A) {A.start("207ad5d2")}) } else { $(flashWidget.start); }});
</script>
</head>
<body class=" hasGoogleVoiceExt">
<div id="widget" style="height: 100%;"></div>
<div id="sm2-container" class="high_performance swf_error" style="z-index: 10000;"><embed name="sm2movie" id="sm2movie" src="/player/assets/swf-8bc33658/soundmanager2_flash9.swf" quality="high" allowscriptaccess="always" bgcolor="#ffffff" pluginspage="www.macromedia.com/go/getflashplayer" title="JS/Flash audio component (SoundManager 2)" type="application/x-shockwave-flash" wmode="transparent" haspriority="true"></div>
</body>
</html>

I just had a look at this again after giving Adobe a couple of months to get their act together, and the problem is now gone in Chrome and Firefox on XP with version 11.5.502.149 of the Flash player. I haven't checked Ubuntu, but presumably they pushed the change out there too.

Related

link preload doesn't seem to change the download priority level

I'm working on a project where I would like to preload a couple of large videos so I started reading up on timing in network performance and resource prioritization.
I found that when I looked at the Priority column of my network tab in the chrome dev tools, the video priority levels were "low" according to the browser. Normally this would be fine, but we're working on a web VR experience so the videos (or at least the first one) is the foundation of the view.
It seemed like I could use the link tag's type="preload" attribute to raise the priority level of the first video. I tried adding a link tag into a small proof of concept and referenced one of our videos:
<!DOCTYPE html>
<html lang="en">
<head>
<link rel="preload" as="video" type="video/mp4" href="videos/cardboard.mp4" />
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="viewport" content="width=device-width, user-scalable=no, minimum-scale=1.0, maximum-scale=1.0">
<link rel="stylesheet" href="css/main.css">
</head>
<body>
<video src="videos/cardboard.mp4" autoplay width="200" style="border:1px solid green"></video>
<p class="start-button">Start</p>
</body>
</html>
When I review the network tab in the dev tools the video's priority level still shows as "Low", but the video started loading at the same time that the "Highest" priority resource (the css) was loaded:
When I comment out the preload link it does seem like the video's load timing is queued until after the CSS is finished:
So it seems like the preload is working, but I'm not sure if the preload is working and chrome isn't updating the Priority value, or if the load time is different because without the preload link tag the css is referenced before the video tag.
i.e. Am I doing it right?!
<link rel="preload"> does not change Chrome's internal "priority" for downloading an asset, it simply instructs Chrome when to start the download.
The resource is loaded with the same priority as it would otherwise, but now the browser knows about it ahead of time, allowing for the download to start earlier.
A stylesheet or font will still be considered Highest priority, and a video will still be considered low priority. But Chrome will start downloading an asset immediately when it encounters the <link rel="preload"> tag.
Note that <link rel="preload"> is a compulsory instruction to the
browser; unlike the other resource hints we’ll be talking about, it’s
something the browser must do, rather than merely an optional hint.
Source: https://developers.google.com/web/fundamentals/performance/resource-prioritization

iOS 8 problems with video player when "apple-mobile-web-app-capable" mode is enabled

Since the iOS 8 was released I have been struggling with an issue on a website I am working on.
We have made a tablet version of a website, and to get a more native app look and feel, we have enabled the apple-mobile-web-app-capable mode. Then we ask our users, first time they load the website, to add the website to the home screen.
When the website is loaded as a normal website in iOS safari browser, the videos work as they should, but in iOS 8, the video does not work in web-app-capable, when you start the web application from the home screen.
I have made a simple test setup, which reproduces the problem.
<!DOCTYPE html>
<html lang="en">
<meta charset="utf-8">
<title>iOS 8 apple mobile web app capable test</title>
<meta name="description" content="Test videoplayer in iOS 8 when adding shortcut to home screen">
<meta name="author" content="TheSourceCodeAuthor">
<head>
<meta name="apple-mobile-web-app-capable" content="yes" />
</head>
<body>
<video width="320" height="240" controls>
<source src="sample.mp4">
Your browser does not support the video tag.
</video>
</body>
</html>
I have tested if it could be a cross domain issue, as our videos are loaded from another domain, then our primary domain name, but that seems not to have any influence on the issue, as I have the same issue if I host the video file on the same domain.
I have been googling for a solution for the problem, but I have been unable to find any solution.
This might be a Bug in Apple iOS 8, but I have not found any official message from Apple about this issue.
Please let me know, if you have been able to fix this issue.
iOS8 doesn't behave the same way with video for some reason.
I've been trying full screen video with no controls on iPad iOS8, works fine iOS6 and iOS7 but I found the only surefire way was to play then immediately pause the video out of view, then using an event listener make sure the video could begin playback and commence playing.
In my case I used the technique of using css translate to hide the video off the page to overcome the quicktime logo bug. .video-overlay is a div with the poster image of the video which gets switched upon playback.
(please excuse the mixture of jQuery and javascript event handlers!)
var videoWrapper = $('#video-active');
var introVideo = $('video')[0];
$(document).ready(function(){
introVideo.addEventListener('canplaythrough', function(){
introVideo.play();
videoWrapper.addClass('active');
$('.video-overlay').hide();
introVideo.removeEventListener('canplaythrough');
});
videoWrapper.on('timeupdate', function(event){
onTrackedVideoFrame(this.currentTime); //this isn't relevant - was using timeline to trigger html text over the top of video at certain points in the timeline.
});
$('.video-overlay').one('click', function(){
introVideo.play();
introVideo.pause(); //hack to force load by playing and then immediately pausing
videoWrapper.one('click', function(){
introVideo.pause(); //pause video
});
});
});

Why does including the "apple-mobile-web-app-capable" tag break my web-app's offline capability on iOS?

I'm trying to create an offline-web app and my cache.manifest file is
CACHE MANIFEST
http://www.page.com/index.html
http://www.page.com/d3.js
http://www.page.com/list.csv
NETWORK:
*
And the beginning of my html is html manifest="cache.manifest"
To format the app and make it run full-screen, I included this tag in the header:
<meta name="apple-mobile-web-app-capable" content="yes" />
But doing that and running it from the homescreen will result in the app failing, and requesting an internet connection.
If you take that one line out and run it from the homescreen, it will open in safari with the url bar and everything, but the app will run correctly.
I've seen this problem discussed in a couple places such as here and here, but never with any working solutions or explanations.
Does anyone know why this is or how to avoid it? Thanks in advance.
<meta name="viewport" content="width=device-width, minimal-ui">
For iOS 7.1, this works as a superior alternative.

Ignore EmulateIE8 in inner iframe in IE9

I'm attempting to embed a "new" style page inside of an older page via iframe, but in IE9, things like border-radius are still having no effect when the page is loaded inside the iframe. When the page is loaded on its own, the rounded corners and effects appear just fine, but when inside the iframe, the css properties seem to be ignored.
Initially I thought this was DOCTYPE inheritance issues, but they're both <!DOCTYPE html> (outer and inner page). Next, I belive it's the content="IE=Emulate8" that's being inherited by the inner iframe. This is, of course, a theory. If it's an incorrect theory, please let me know. :)
Anyway, here's an example of the page:
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta content="IE=EmulateIE8" http-equiv="X-UA-Compatible">
</head>
<body>
... stuff...
<iframe>
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
<meta name="viewport" content="width=device-width,initial-scale=1">
</head>
</html>
</iframe>
</body>
</html>
Some of this may not really be relevant. Anyway, my question is: if the EmulateIE8 is the culprit as to why css properties like border-radius aren't working in the iframe under IE9, is it possible to override it or disable it inside the inner iframe?
Just to note: changing what's outside the iframe is difficult without changing the entire framework of the application, unfortunately (legacy apps *sigh*). I'm attempting to put something a little more modern inside of the legacy application.
As noted here:
As of IE9 mode, webpages cannot display multiple document modes. For example, consider a standards-based webpage that contains a frame element that displays content in quirks mode. IE9 mode displays the child frame in standards mode (because the parent document is in standards mode). Starting with Internet Explorer 10, however, child frames can emulate quirks mode. For more info, see IEBlog: HTML5 Quirks mode in IE10. For best results, however, use document modes consistently.

MJPEG in Chrome mobile

I have a stream from IP-Camera. It works great in safari and adequately in opera mini, but on chrome i recive nothing or if directly open stream i get this:
To display i use this code
<input width="320" type="image" height="240" border="0" id="Сamera" src="url">
You may be experiencing Chrome Issue 135337, in which MJPEG images fetched directly fail to animate.
Reportedly, it's fixed in version 22. So, you can either upgrade to that version or change your code to embed the image in an HTML page. E.g., the following works in Chrome 21 (even if nothing's going on, the timestamp should still increment):
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<title>
Test MJPEG Animation
</title>
</head>
<body>
<h2>
Test MJPEG Animation
</h2>
<img src="http://193.40.245.181/mjpg/video.mjpg">
</body>
</html>
However, simply pointing the browser at http://193.40.245.181/mjpg/video.mjpg shows only the first frame.
You could also try this node.js proxy. It parses m-jpeg streams and delivers images to all browsers.
Cross-browser solution for displaying MJPEG stream