How do I use the code if element.requestFullscreen() is undefined?
if (element.webkitRequestFullScreen) {
element.webkitRequestFullScreen();
}
If requestFullscreen returns undefined, it means that you cannot request fullscreen because that function doesn't exist. Every browser other than IE10 and below supports it but you need to use the right vendor prefix as you commented. A good way you can do that is by doing
var requestFullScreen = elem.requestFullscreen || elem.msRequestFullscreen || elem.mozRequestFullScreen || elem.webkitRequestFullscreen;
I think your issue is you spelled some of the functions wrong. it's confusing because Mozilla uses .mozRequestFullScreen whereas the others use requestFullscreen. The capital S can be annoying.
where elem is the video element from the DOM. You can then do requestFullScreen.call(elem) and it will initiate fullscreen.
And as #ArunPJohny commented, definitely take a look at that MDN article.
Related
I have some old JavaScript code that I can't change crashing on IE10 (I can change other script files).
Here is the crashing code:
if(isInternetExplorer && this.domElement.filters[0])
this.domElement.filters[0].play()
That code will not crash in ie8/9 because the DOM element has the non standard property "filters".
Here is the documentation to the filters property.
The only solution I can think of is to change the HtmlElement's prototype but I don't feel like it is actually possible or the good thing to do.
So how can I prevent IE10 from crashing when it tries to use the DomObject.filters property?
[EDIT]
I just found a 'solution'. This is also #JAM's solution.:
if (!HTMLDivElement.filters) {
HTMLDivElement.prototype.filters = [];
}
But I still feel bad about modifying a browser native object's prototype.
As you said, overriding the prototype of the object is one way of doing it; so if there is no other alternative you could try this:
Object.prototype.filters = Object.prototype.filters || []
Or even better (as you suggested your self):
HTMLDivElement.prototype.filters = HTMLDivElement.prototype.filters || []
This will set the filters property of the object, if it is non-existing.
Umm, use feature detection instead of browser detection? No isInternetExplorer please, but doesSupportFilters:
var el = this.domElement;
if (el.filters && el.filters.length && typeof el.filters[0].play == "function")
el.filters[0].play();
I didn't notice it in Modernizr's documentation but I imagine you create a menu element then check if it exists? My only concern is that the browser may support that but not type context. Any ideas? Thanks.
I have come up with a rather shoddy solution that returns true for Firefox as far as I can tell then returns false for Chrome, IE and Opera. Check it out:
// Detect context menu support.
function contextMenuSupported() {
var oMenu = document.createElement("menu");
// Kind of backwards but seems to work.
if (oMenu.type == "list")
return true;
return false;
}
Let me know if that just horrifies you. It seems when a menu element is created with a browser that supports it, certain attributes are intrinsically defined.
How to check with JS if flash is installed, or not? I don't want to detect the version, or other informations. I want to check only, if it's avaiable, or not.
The swfobject library makes it (and many other things, which are unneccessary for that), but I don't want to use a library for only one function.
If you’re using Flash to progressively enhance a document, please use this script to feature detect it first.
var hasFlash = ((typeof navigator.plugins != "undefined" && typeof navigator.plugins["Shockwave Flash"] == "object") || (window.ActiveXObject && (new ActiveXObject("ShockwaveFlash.ShockwaveFlash")) != false));
hasFlash will be true if Flash is available, or falsy if it isn’t.
If you already have access to the Flash element you want to use then you could just do:
var hasFlash = 'Pan' in element;
Source: https://gist.github.com/675496
You can check if Flash is installed (see Mathias answer) but be aware that even if Flash is installed is still may be disabled (see here for examples http://blog.lroot.com/articles/techniques-to-easily-disable-flash-in-firefox-and-ie/) so your movies won't play at all.
I am using this in a Firefox extension and can't get it to work.
var allLinks = document.evaluate(
'//a[#href]',
window.document,
null,
XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE,
null);
window.alert(allLinks);
This alerts [object XPathResult]. However the following always returns 0. (And there are certainly links on the page).
window.alert(allLinks.snapshotLength);
If it's firefox specific and I assume you only use new versions.. can't you use querySelectorAll?
document.querySelectorAll('a[href]')
Also - are you doing it when the DOM has fully loaded? bind it to DOMContentLoaded or something.
document.addEventListener('DOMContentLoaded', fn, false);
EDIT: Your xpath works for me. Did it in the console on an existing, loaded page. Pretty sure you're querying before anything exists.
The answer that you don't want to hear - "works for me".
See this example (alerts 3 for me).
What browser and what version are you testing this on?
This worked.
var allLinks = top.document.getElementById("content").selectedBrowser.contentDocument.evaluate(
treeView.model[0].xpath,
top.document.getElementById("content").selectedBrowser.contentDocument,
null,
XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE,
null);
I've been searching for this for a couple of days now and so far, the best I can come up with is checking the list below. I really don't like to check for support based on User-Agent, especially since it can be spoofed. I've also heard of at least one instance where the list below is incorrect (noted below).
Is Internet Explorer?
Is WebKit? (But I've read that mobile Safari doesn't support it)
Is Opera?
Is Gecko and version >= 1.9? (meaning Firefox 3 or later)
Is there a better method based on testing for support directly via JavaScript, or is this pretty much the only way to test for support?
var canEditContent= 'contentEditable' in document.body;
The best way to check for a certain feature is to actually test for that feature on an element that you know should support it, like this:
if(element.contentEditable != null)
// then it's supported
or
if(typeof(element.contentEditable) != 'undefined')
// same thing.. but with typeof you can be more specific about the type of property you need to find
The best solution for my scenario (similar to yours) I came up with is below. It's not probably bulletproof, but covers most of the situations:
var ua = navigator.userAgent;
var android_version = ua.match(/Android ([0-9\.]+)/);
var div = document.createElement("DIV");
if( typeof(div.contentEditable) == 'undefined' ||
(/(iPhone|iPod|iPad)/i.test(ua) && /OS [1-4]_\d like Mac OS X/i.test(ua)) ||
(android_version!=null && parseFloat(android_version[1])<3 ) ||
(/(Opera Mobi)/i.test(ua))
) {
// doesn't support contenteditable
} else {
// supports contenteditable
}
You can test it out in this jsFiddle.
Notice: Depending on your needs and purpose, you might need to detect IE version as well, because it's support of contenteditable is ... "not ideal" :-) Most of the pains is dealt by super library Rangy.js.
bobince's answer works for the most part but, as has been said, you will need user agent sniffing to exclude iOS and Android versions that don't bring up the software keyboard. I'm currently using something like this:
function isContentEditable() {
var canEditContent = 'contentEditable' in document.body;
if (canEditContent) {
var webkit = navigator.userAgent.match(/(?:iPad|iPhone|Android).* AppleWebKit\/([^ ]+)/);
if (webkit && parseInt(webkit[1]) < 534) {
return false;
}
}
return canEditContent;
}
This should stop older iOS and Android devices from returning true. It still has one problem though: physical keyboards. If, for example, a device is running Android 2.3 but has a physical keyboard then the user will be able to use contentEditable but this function will return false. Physical keyboards are quite rare though.
More commonly, on some devices it may be possible for the user to bring up the on screen keyboard by pressing and holding the menu button. Obviously this isn't really something you should expect your users to know about.
You could mitigate these issues slightly by having some way for the user to manually override the sniffing part of the detection script. You could implement this in the isContentEditable function by adding an override check to "if (canEditContent)". However, Implementing the UI for this might present more of a challenge ;).