Develop Reference

How to check if webkitdirectory works using 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
}

JavaScript Element.requestFullscreen() is undefined

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.

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.

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