How to check if webkitdirectory works using javascript? - javascript

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
}

Related

How to prevent IE10 from crashing when it tries to use the DomObject.filters property?

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();

What does $ means in JavaScript and how can I replace it in a Win8 application?

Example in:
JsDatePick.prototype.setC = function(obj, aClassName){
if (this.isie && this.iever > 7){
$(obj).attr("class", aClassName);
} else {
obj.className = aClassName;
}
};
Source: http://javascriptcalendar.org/
It is a variable name. It has no special meaning in the language.
A number of libraries (including jQuery and Prototype.js) hang their main function off it.
Before you can replace it (on a general scale), you will have to determine which piece of code is assigning a value to it in the first place.
In this particular case, you can forget about it since all browsers that support setting a class attribute programatically also support setting the className property (which the else clause does).
Did you read the site?
Download includes jsDatePick standard full/minified, and jsDatePick
for jQuery full/minified.
They already have a non jQuery version.

Detect HTML5 Context Menu Support with JavaScript?

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?

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.

How do I detect support for contentEditable via JavaScript?

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 ;).

Categories

Resources