We use the html5-video-tag.
Sometimes we get only one video-source (.mp4).
For browsers which does not support the html5-video - all is OK, there the fall-back method works:
<video>
<object with flash></object>
</video>
Problem occurs if only a .mp4 is provided. The Firefox only displays "Kein Video mit unterstützem Format und Mime-Type gefunden". Yes Firefox cannot display .mp4 videos.
What can I do to force the Firefox (or any browser which does not support the mime-type) to show the alternative object-flash-section?
Exists an attribute for the html5-video-tag to force pass-through on error?
Or can I catch an Event "onerror" ...?
You can use JavaScript to detecter wether a file type is supported :
(function (video) {
if (!video.canPlayType || !video.canPlayType('video/mp4')) {
// Flash fallback
}
}(document.createElement('video')));
As said in HTML5 video, fallback to flash if no .ogv file
Related
I dont' really know if this is a SO question or SF question.
I'm using flowplayer 5.2.0. The video is prepared for streaming using ffmpeg (moov moved to file head, encoded with h.264 and etc). But, using debug: true option i see the following output:
Object {url: "http://188.254.8.34/video/2012/03/20/jvk6abVbQog.mp4", seekpoints: Array[20], src: "http://188.254.8.34/video/2012/03/20/jvk6abVbQog.mp4", width: 1280, seekable: false…}
This media file is not seekable. But:
debug.metadata Object {videoframerate: 25, seekpoints: Array[20], audiocodecid: "mp4a", moovposition: 40, audiochannels: 2…}
There are some seekpoints.
What should i do to make this file seekable?
Mp4's are served by nginx with mp4 module -- range requests are supported.
EDIT:
I have a hypothesis that i need to fragment mp4 by keyframes. But i don't know how to do it with ffmpeg v.>0.8.
Looks like flowplayer (it's non-flash version) does not support HTTP Progressive download. It's flash version does, however.
OK, so I use Respond.js a polyfill for mediaqueries on legacy browsers (ie8 being the most important).
At the same time I'm investigating in using Enquire.js which enables executing js-code based on media-query matches.
Tested in isolation this stuff works:
respond.js executes media-queries defined in css correctly for IE8
enquire.js executes javascript code correctly based on media-queries matching css. (for NON-legacy browsers)
However the combi doesn't seem to work. I.e:
Enquire.js doesn't execute javascript based on a media-query which gets enabled through respond.js (for legacy browsers)
Since Respond.js contains Paul Irish's polyfill for MatchMedia which (as per: Enquire's documentation) should be enough for legacy support, I'm not sure what could be wrong.
So just to be checking: this combination should work right?
I'm the author of enquire, so i'll help where i can.
I've just browsed through the respond.js source to find out how it works. Respond extracts any media queries from your CSS, then depending on the width of the window it will create new style blocks containing that CSS if the media query matches (this is why it only supports simple media queries such as max/min-width). This of course means that it will not help enquire JS, as it is simulating media queries.
The inclusion of the matchMedia polyfill is actually a red herring. All that does is create an equivalent to the matchMedia browser API. Thus if the browser only supports very limited set of media queries (as IE8 does), it will not expand it's capabilities, it will only allow you to work within it's means. I made this mistake myself at first!
I don't know if this will help you, but enquire's register method can accept a third parameter, shouldDegrade which is a signal to enquire that you intend the functionality to always run if the browser is deemed incapable. Thus if you pass in true, the match function will always be executed for incapable desktop browsers (whilst still being conditional for capable browsers). This will allow you to deliver a desktop experience to older browsers, especially useful in mobile-first approaches.
Happy to help further if you have any more questions
Try removing the inclusion of matchMedia from respond.js, and then loading match.media and enquire.js after respond.js. Worked for me in IE 7 and 8 with enquire v 2.0.2.
I found a solution that seems to work for IE8
1.Very important ! Remove match.media from respond JS if you use it (if not it will silently fail in IE)
2.Include Modernizr with at least mediaqueries testing, load, shiv : http://modernizr.com/download/#-shiv-mq-cssclasses-teststyles-load
3.In < head > (because we need respondjs in head)
<script src="../../common/vendor/modernizr/modernizr.custom.js"></script>
<script>
Modernizr.load([
// Test need for CSS media query polyfill
{
test: Modernizr.mq("only all"),
nope: "../../common/vendor/respond/respond.min.js"
}
]);
</script>
4.Before < /body > tag to load polyfill and your scripts
<script>
Modernizr.load([
{
test: window.matchMedia,
nope: [
"../../common/vendor/polyfills/media.match.js",
"../../common/vendor/polyfills/matchMedia.addListener.js"
]
},
'../../common/vendor/enquire/enquire.min.js',
'../../common/scripts/script.js'
]);
</script>
I hope it will work for you !
I'm using the chrome://favicon/ in my Google Chrome extension to get the favicon for RSS feeds. What I do is get the base path of linked page, and append it to chrome://favicon/http://<domainpath>.
It's working really unreliably. A lot of the time it's reporting the standard "no-favicon"-icon, even when the page really has a favicon. There is almost 0 documentation regarding the chrome://favicon mechanism, so it's difficult to understand how it actually works. Is it just a cache of links that have been visited? Is it possible to detect if there was an icon or not?
From some simple testing it's just a cache of favicons for pages you have visited. So if I subscribe to dribbble.com's RSS feed, it won't show a favicon in my extension. Then if I visit chrome://favicon/http://dribbble.com/ it won't return right icon. Then I open dribbble.com in another tab, it shows its icon in the tab, then when I reload the chrome://favicon/http://dribbble.com/-tab, it will return the correct favicon. Then I open my extensions popup and it still shows the standard icon. But if I then restart Chrome it will get the correct icon everywhere.
Now that's just from some basic research, and doesn't get me any closer to a solution. So my question is: Is the chrome://favicon/ a correct use-case for what I'm doing. Is there any documentation for it? And what is this its intended behavior?
I've seen this problem as well and it's really obnoxious.
From what I can tell, Chrome populates the chrome://favicon/ cache after you visit a URL (omitting the #hash part of the URL if any). It appears to usually populate this cache sometime after a page is completely loaded. If you try to access chrome://favicon/http://yoururl.com before the associated page is completely loaded you will often get back the default 'globe icon'. Subsequently refreshing the page you're displaying the icon(s) on will then fix them.
So, if you can, possibly just refreshing the page you're displaying the icons on just prior to displaying it to the user may serve as a fix.
In my use case, I am actually opening tabs which I want to obtain the favicons from. So far the most reliable approach I have found to obtain them looks roughly like this:
chrome.webNavigation.onCompleted.addListener(onCompleted);
function onCompleted(details)
{
if (details.frameId > 0)
{
// we don't care about activity occurring within a subframe of a tab
return;
}
chrome.tabs.get(details.tabId, function(tab) {
var url = tab.url ? tab.url.replace(/#.*$/, '') : ''; // drop #hash
var favicon;
var delay;
if (tab.favIconUrl && tab.favIconUrl != ''
&& tab.favIconUrl.indexOf('chrome://favicon/') == -1) {
// favicon appears to be a normal url
favicon = tab.favIconUrl;
delay = 0;
}
else {
// couldn't obtain favicon as a normal url, try chrome://favicon/url
favicon = 'chrome://favicon/' + url;
delay = 100; // larger values will probably be more reliable
}
setTimeout(function() {
/// set favicon wherever it needs to be set here
console.log('delay', delay, 'tabId', tab.id, 'favicon', favicon);
}, delay);
});
}
This approach returns the correct favicon about 95% of the time for new URLs, using delay=100. Increasing the delay if you can accept it will increase the reliability (I'm using 1500ms for my use case and it misses <1% of the time on new URLs; this reliability worsens when many tabs are being opened simultaneously). Obviously this is a pretty imprecise way of making it work but it is the best method I've figured out so far.
Another possible approach is to instead pull favicons from http://www.google.com/s2/favicons?domain=somedomain.com. I don't like this approach very much as it requires accessing the external network, relies on a service that has no guarantee of being up, and is itself somewhat unreliable; I have seen it inconsistently return the "globe" icon for a www.domain.com URL yet return the proper icon for just domain.com.
Hope this helps in some way.
As of Oct 2020, it appears chrome extensions using manifest version 3 are no longer able to access chrome://favicon/* urls. I haven't found the 'dedicated API' the message refers to.
Manifest v3 and higher extensions will not have access to the
chrome://favicon host; instead, we'll provide a dedicated API
permission and different URL. This results in being able to
tighten our permissions around the chrome:-scheme.
In order to use chrome://favicon/some-site in extension. manifest.json need to be updated:
"permissions": ["chrome://favicon/"],
"content_security_policy": "img-src chrome://favicon;"
Test on Version 63.0.3239.132 (Official Build) (64-bit)
chrome://favicon url is deprecated in favor of new favicon API with manifest v3.
// manifest.json
{
"permissions": ["favicon"]
}
// utils.js
function getFaviconUrl(url) {
return `chrome-extension://${chrome.runtime.id}/_favicon/?pageUrl=${encodeURIComponent(url)}&size=32`;
}
Source: https://groups.google.com/a/chromium.org/g/chromium-extensions/c/qS1rVpQVl8o/m/qmg1M13wBAAJ
I inspected the website-icon in Chrome history page and found this simpler method.
You can get the favicon url by --
favIconURL = "chrome://favicon/size/16#1x/" + tab.url;
Don't forget to add "permissions" and "content_security_policy" to Chrome. (https://stackoverflow.com/a/48304708/9586876)
In the latest version of Chrome, Version 78.0.3904.87 (Official Build) (64-bit)) when tested, adding just img-src chrome://favicon; as content_security_policy will still show 2 warnings:
'content_security_policy': CSP directive 'script-src' must be specified (either explicitly, or implicitly via 'default-src') and must whitelist only secure resources.
And:
'content_security_policy': CSP directive 'object-src' must be specified (either explicitly, or implicitly via 'default-src') and must whitelist only secure resources.
To get rid of them use:
"permissions": ["chrome://favicon/"],
"content_security_policy": "script-src 'self'; object-src 'self'; img-src chrome://favicon;"
Now you can use chrome://favicon/http://example.com without getting any errors or warnings.
In my Cocoa app, I want to prevent Flash from loading in a WebView, and let the user decide if the Flash should be shown for each page. (That's the same behavior already available through the ClickToFlash plugin or Safari extension. Bundling any of those extensions is probably not an option because of licensing issues.)
Unfortunately most of the Flash I'm trying to avoid is generated from embedded JavaScript specifically designed to prevent easy flash blocking, so I cannot filter the raw HTML for inclusion of Flash objects.
Also, I cannot disable JavaScript for my WebView, as the page I want to display looks completely different when JavaScript is turned off.
Is there a notification/hook I can use to modify the page DOM after JavaScript has been executed, but before the Flash plugin is loaded?
Or should I pursue a different direction?
Thanks,
Ilja
Ideally, you would just define your own WebKit plug-in that handles the application/shockwave-flash MIME type and make your plug-in do nothing.
However, there is unfortunately no way to control the priority of multiple WebKit plug-ins that all register for the same MIME type. The loading order of WebKit plug-ins is totally random and arbitrary, so you cannot guarantee that your plug-in will handle the Flash object instead of the Flash plug-in.
The only way around this that I've found is to subclass WebView and override the private method -_pluginForMIMEType: like so:
#class WebBasePluginPackage;
#interface WebView ( MyFlashPluginHack )
- (WebBasePluginPackage *)_pluginForMIMEType:(NSString *)MIMEType;
#end
#implementation MyWebView
- (WebBasePluginPackage *)_pluginForMIMEType:(NSString *)MIMEType
{
if ( [MIMEType isEqualToString:#"application/x-shockwave-flash"] )
{
return [super _pluginForMIMEType:#"application/my-plugin-type"];
}
else
{
return [super _pluginForMIMEType:MIMEType];
}
}
#end
Then you just need to create a custom WebKit plugin to handle "application/my-plugin-type" and have that plug-in do nothing at all.
Okay, we pretty much figured this out.
Since there is no official API that lets the host app know when JavaScript has finished or control what plugin should load, we are now using custom JavaScript that gets inserted into the received HTML we want to display.
The ClickToFlash Safari extension (not the Internet plugin, which it is based on) was a good inspiration.
:-moz-system-metric(touch-enabled) looks like a really useful CSS selector for working on mobile sites.
Unfortunately Webkit is dominant on mobile touch devices so does anyone know if there is a Webkit equivalent?
(Ideally it'd be good if this was managed by CSS3 media queries)
Edit: Looks like it is supported in Gecko as a media query
There's no way to accomplish this without resorting to Javascript, at present.
As #easwee said, Modernizr is a well-regarded JS library that focuses on feature detection. You can use its touch test for your use case.
If you don't need all of Modernizr's bells and whistles, you can do the following:
A) Load the following JS as early in your <body> tag as you can:
<script type="text/javascript">
if( !!window.TouchEvent ) body.className += " touch-enabled ";
</script>
B) Write your CSS. Since Gecko uses a media query to inform you of touch availability, you'll have to dupe the touch-specific CSS, like so:
BODY.touch-enabled DIV.foo
{
/* touch-specific CSS */
}
#media screen and (-moz-touch-enabled)
{
DIV.foo
{
/* touch-specific CSS */
}
}
If the per-selector code is identical in both circumstances, GZIP ought to optimize away some of the duplication. (You are using compression, I hope.)
In Ian Wessman's answer the test !!window.TouchEvent works incorrectly. In current desktop Chrome (23.0.1271.52, Linux) window.TouchEvent is a function, so Ian's code considers the browser touch-enabled.
If you want short code, it's probably best to copy-paste the relevant code from Modernizr.
Chrome is another browser that tried to implement a similar selector but unfortunately it was removed out for now.
Modernizr could be and interesting detection tool since it can detect touch events too.
http://www.modernizr.com/docs/#touch