Develop Reference

JS Error with for(var key of...)

I have some code that I have been using in an application for some time now where all of our internal users are using firefox for running the app. There are a few people wanting to run IE and there is a block of code that I believe is hitting an error and I don't know exactly why..
// Given a field name, check to see if its in our output. If so, return the formatted link
function createLink(field, val) {
var output = {
'ntid': 'https://web.internal/profile/' + val,
'email': 'mailTo:' + val
};
for (var key of Object.keys(output)){
if (field.toLowerCase().includes(key)){
return `${val}`;
}
}
return val;
}
In IE 11, I get a console error SCRIPT1004: Expected ';' which refers to the line for (var key of Object.keys(output)){.
Is this not supported in IE11 or is there some type of syntax that FF handles correctly that IE doesn't?

Instead of the "for...of", try a "for...in" which is supported by every browser for a long time now. Syntax is exactly the same.
(There is a difference between them but I guess in your case it's not relevant... More about this here: What is the difference between ( for... in ) and ( for... of ) in javascript? )

Instead of the "for...of", try a "for...in" which is supported by
every browser for a long time now. Syntax is exactly the same.
Not entirely:
https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Statements/for...of

Unable to get property 'options' of undefined or null reference

i am getting the above error in ie 10 please give me a suggestion.it is working fine in
function getSelectedIndex(element, value) {
var selectedIndex = 0;
for(i = 0; i < element.options.length; i++) {
if(element.options[i].value == value) {
selectedIndex = i;
break;
}
}
return selectedIndex;
}
element.options.length is giving Unable to get property 'options' of undefined or null reference.please suggest me a sample code.
Edit : It was working for me when I was using IE11 with compatibility mode, but when I removed it and ran it in normal mode, the above issue occurred.

Use elements.options.indexOf(value) (assuming element is defined, which it doesn't seem to be). By the way, your current design will return zero if the first element matches or there is no match at all. If you really want to write your own version of indexOf, better to return -1 in the case of no match as it does.

actually the message gives you exactly what you need to know.
you are trying to read a property of something that does not have a value, and here it is "element" or "element.options", check the place where they are set before the function call.
for IE10 it's a strict one, it doesn't support the use of
element.options.length
instead you should use:
document.getElementById("optionsID").value
I hope this helps

jQuery doesn't work in Internet Explorer 8 ("this" returns DOM instead of jq)

I am facing a strange problem and can't find any solution.
jQuery (any version, from 1.7.* to 1.10.*) fails in Internet Explorer 8. All plugins (from bootstrap) and the jQuery library fall with an error:
Object doesn't support this property or method
Screenshot from debugger:
Digging in plugins code, like this:
$.fn.alert = function (option) {
return this.each(function () {
//...
})
}
shows the problem: this keyword points to HTMLDomObject, not on a jQuery object.
What can cause such a weird error?
Only in Internet Explorer 8!

Some other code or plugin may be loading another JavaScript library and that calling code may not be taking care of jQuery.noConflict(). This has happened to me several times. In the meantime, to make your code work, you can also do the following:
//If 'this' is pointing to a HTMLDomObject
var obj = $(this)

I've found a piece of code, that caused this problem. I still don't understand, how it could break all jQuery in such way and why it was breaking at all (again, it worked perfectly in all browsers but Internet Explorer 8), but changing the for in iterator to $.each() made errors to disappear.
for (var i in $postsPortions) {
var $p = $($postsPortions.get(i));
var offset = $p.offset();
if (offset && Math.abs(offset.top - scrollTop) < 100) {
var year = $p.data('year');
var season = $p.data('season');
window.location.hash = year + '/' + season;
$milestones.removeClass('active');
$milestones.filter('.year_' + year + '.season_' + season).addClass('active');
return;
}
if (i >= ($postsPortions.length - 1)) return;
}

When you use jQuery.each method, "this" (in callback) points to DOM element, not to jQuery wrapper. As follows, you have to wrap "this" in jQuery object:
$elements.each(function(){
var $this = $(this);
// do something with $this ...
});

Portability of nextElementSibling/nextSibling

I'm currently writing an accordion and running into the same problem as described in nextSibling difference between IE and FF? - specifically differences between Microsoft's nextSibling / nextElementSibling and that implemented by everyone else.
For various reasons, using jquery is not an option. Nor is getting all my MS users to upgrade to MSIE9
Currently I'm using the following code to work around the problem:
// tr is a TR doc element at entry....
while (nthRow--) {
// for Chrome, FF tr=tr.nextElementSibling; for MSIE...tr=tr.nextSibling;
tr=tr.nextElementSibling ? tr.nextElementSibling : tr=tr.nextSibling;
if (!tr || tr.nodeName != "TR") {
break;
}
tr.style.display="";
}
Which seems to do what I expect in MSIE6, FF and Chrome - i.e. the nthRow TR elements below the initial TR are made visible (previously style.display="none").
But is this likely to have unexpected side effects?
(I'm a bit of a newbie with Javascript ;)

nextSibling will see HTML code comments, so be sure to keep them out.
Other than that you should be alright since you won't have any text nodes between your tr elements.
The only other issue I could think of would be in Firefox 3 where nextElementSibling hadn't yet been implemented. So if you're supporting that browser, you'll need to manually emulate nextElementSibling. (Pretty sure they had it implemented in FF3.5 though.)
You'll be safer to create a nextElementSibling() function:
tr = tr.nextElementSibling || nextElementSibling(tr);
function nextElementSibling( el ) {
do { el = el.nextSibling } while ( el && el.nodeType !== 1 );
return el;
}

Considering previous answers, I am currently implementing it this way to grant cross-browser compatibilty:
function nextElementSibling(el) {
if (el.nextElementSibling) return el.nextElementSibling;
do { el = el.nextSibling } while (el && el.nodeType !== 1);
return el;
}
This way, I can avoid the do/while loop for browsers that support nextElementSibling.
Maybe I'm too scared of WHILE loops in JS :)
One advantage of this solution is recursability:
//this will always works:
var e = nextElementSibling(nextElementSibling(this));
//this will crash on IE, as looking for a property of an undefined obj:
var e = this.nextElementSibling.nextElementSibling || nextElementSibling(nextElementSibling(this));

Firefox nextSibling returns whitespace \n while Internet Explorer does not.
Before nextElementSibling was introduced, we had to do something like this:
var element2 = document.getElementById("xxx").nextSibling;
while (element2.nodeType !=1)
{
element2 = element2.nextSibling;
}

How to use feature detection to know if browser supports border-radius? (Including IE9)

I've seen plenty of examples for detecting support for border radius using something like:
var cssAttributeNames = ['BorderRadius', 'MozBorderRadius', 'WebkitBorderRadius', 'OBorderRadius', 'KhtmlBorderRadius'];
for (var i = 0; i < cssAttributeNames.length; i++) {
var attributeName = cssAttributeNames[i];
if (window.document.body.style[attributeName] !== undefined) {
this._useCss = true;
break;
}
}
But this doesn't seem to work for IE9, which does support border-radius. Am I missing something?

Got it - the detection array needs 'borderRadius' added - it's case-sensitive.

Modernizr is a Javascript library used to detect HTML5 features (including border-radius), so if you're looking for a ready made solution, check that out.