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.
Related
In my web app, I am using folder select on an input field. This is the feature
https://caniuse.com/#search=webkitdirectory
However, I am also doing some compatibility checking to make sure the feature exists before the user tries to use it. Is there a way I can quickly check in javascript to see if this feature exists?
I am looking for something similarly for if I want to check if webworkers exist, I can do if (window.Worker) {}
Does anyone know?
Thanks
In supported browsers, an HTMLInputElement will have the property webkitdirectory set to true or false.
We can use this fact to check compatibility:
var input = document.createElement("input");
if(typeof input.webkitdirectory !== "boolean") {
// not supported
}
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.
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'm integrating a mootools script onto a page which has very old JavaScript functions which run a navigation vertical menu. This old script will be hard to change now.
The line breaking is:
function stgobj(id) {
with(document) return nIE && nVER < 5 ? all[id] : nNN4 ? layers[id] : getElementById(id);
}
Not sure exactly what's it's purpose, but it looks like it's rendering some elements. If commented the menu will disappear.
FF, Chrome, IE(doesn't crash, but menu does not render)
Any quick patch to resolve the browsers crashing?
Looks like its purpose is to return the element corresponding to the given ID. The code simply uses some different methods based on the browser - document.all for IE5 and earlier, and document.layers for Netscape 4. Unless you need to support those ancient browsers, you could alter the function to return just document.getElementById(id). Or better yet, ditch this function altogether and call document.getElementById directly.
However, if it's crashing modern browsers like Firefox and Chrome, then you should also look at the browser detection logic (the code that populates the nIE, nVER and nNN4 variables), otherwise it might just end up crashing elsewhere.
It's a "compatibility" function for document.getElementById. I think you should be able to equal it:
stgobj = document.getElementById.bind(document);
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 ;).