I had a jQuery Syntax-Error in my Script but only Safari throw an exception.
$("#id:not(.class").length
The :not wasn't closed by ). In Safari length was 0, in all other browser it was the correct value if the error hadn't exist. Could it possible that Chrome, Firefox, Opera and Internet Explorer fixes these errors on the fly?
Additionally, it seems not to be inherent to jQuery, because even native querySelector calls recovers syntax errors in the selector literal:
document.querySelector('[href^="h' ) ===
document.querySelector('[href^="h"]'); // true in non-Safari
document.querySelector(':not([X="Y' ) ===
document.querySelector(':not([X="Y"])'); // true in non-Safari
Error raised in Safari reads SYNTAX_ERR: DOM Exception 12.
This is really somehow fascinating because I have asked myself this a lot of times, too, without further investigation why that is. Chrome indeed sometimes "ignores" syntax errors, for example when you add or leave out ; or , in object notations for instance.
That can be a good thing but is sometimes hard to debug. Older browsers like IE throw errors where newer browsers dont. I dont know if this is a feature or a bug :)
I dont have sources on this but I can confirm that I noticed similar behavior. Most likely this has something to do with JavaScipt's strict mode.
This should be
$("#id:not('.class')").length
instead of
$("#id:not(.class").length
Related
I am using an external library called "deps.js". I forked it on github and modified it a little bit. You can find it here:
https://github.com/ckosmowski/jquery-interdependencies/blob/master/deps.js
Unfortunately i'm stuck to the quirks mode of ie9. i'm getting the following error:
SCRIPT16386 Schnittstelle nicht unterstützt
(Which can be translated to "interface not supported")
The error message is refering to:
jquery-1.7.js, Line 5244 Character 3 which is:
if ( document.documentElement.contains ) {
Sizzle.contains = function( a, b ) {
return a !== b && (a.contains ? a.contains(b) : true); //This is the line from the error message
};
In Standards mode this does not appear.
What causes this problem?
How to find out what causes this problem?
Reposting comment as an answer, as suggested by OP...
If you really are stuck on quirks mode, then the chances are you're not going to be able to fix this. Quirks mode is an IE5-compatibility mode, and deliberately removes tons of features from the browser to try to be IE5 compatible.
You really shouldn't be using quirks mode for anything these days, and frankly, you shouldn't need to be stuck on it either -- converting a site to work in standards mode usually isn't that difficult. (look up box-sizing:border-box; it will solve most of the conversion problems)
I don't think that this solves the main problem but the symptoms mentioned in the question seem to be solved with newer jQuery versions. I just changed the jQuery version from 1.7 to 1.10.2 and now it works perfectly in quirks mode.
This is a simple app simulating a chat. I provide jsfiddle:
http://jsfiddle.net/LkqTU/2785/
Some messages coming from the server, simulated by the button, and a user typing on a textarea binded to the keypress event to get te enter key and send the message.
Well, this is working fine in Chrome and Firefox but fails in IE9.
What could be wrong?
Thanks
Well, it was relatively easy to locate an error: assigning this to an external variable named self right at the beginning of Model function just doesn't look right.
The explanation why it worked fine in Chrome and Firefox, but failed in IE, though, is much more interesting. Obviously varless self refers to window.self, which is actually a special property of window object - reference to... window itself (MDN).
Internet Explorer is actually well-known for its specific treatment of this property: while in other browsers window === window.self evaluates to true, in IE it's false. And I wouldn't say IE does it without any reasoning; check this discussion for some details.
Ironically, in this particular example IE turns out to be a half-hero. ) I said "hero", because IE is the only browser that doesn't let you overwrite window.self. All the others are not so picky; add console.log(window.self) to the end of your script to witness their shame. )
And I said "half", because IE could be much more... heroic about it. ) Instead of ignoring window.self = ... line silently (and throwing an error for that far away line that used the ignored assignment in a slightly different way), why didn't IE just give an early warning? Damn, even a notice would do.
Anyway. It's pretty easy not to rely on IE's sporadic heroism for such things: just add 'use strict' line at the beginning your script, and voila! both Chrome and Firefox will spit out a 'Reference Error' warning right where it belongs - at self = this line. )
Yes, I understand that 'use strict' use is not a simple step, and it might break some scripts; yet I wholly stand by Nicholas Zakas' statement on that topic.
Can anyone suggest a Javascript IDE that will help me with debugging, for example be able to tell me which .js file & which function/line caused a crash?
I am currently using Notepad2 & its extremely difficult if not impossible to figure out why the app is crashing. Right now if I attempt to print out the object/variable causing the crash using...
alert(obj);
...It causes a crash. It is really frustrating because something weird is happening where just accessing the variable - ie passing the variable in a function as a parameter or alerting it - causes Firefox to have a catastrophic crash & Safari just has no failure output(I'm sure the error occurs but it recovers gracefully).
Ever experienced this kind of problem with Javascript before? Maybe you can say "I know what that is because its happened to me before, its x doing y"?
For example: "I know what that is because its happened to me before, your calling a prototype/object static function as a member function"
Internet explorer have Console ( in IE 8 and IE 9 console is usable ) - press F12
Firefox have plugin named firebug
Chrome and Opera have built in consoles ( Press Ctrl + Shift + I )
All of them know what it is break point, can watch some variables etc.
Chrome speciality is break on event.
IE speciality is break on error, and recover from error.
All of them allows you to find out place where script crashes
Most modern browsers come with a Javascript debugger. Safari/Chrome have the Script area in the Webkit Inspector. It allows you to set breakpoints, step through code and inspect variable states. Firefox has something similar in Firebug.
Why does this expression:
typeof document['domConfig']
throw an error in Firefox (4)?
All the other browsers (IE9, Chrome 10, Safari 5, Opera 11) do not throw an error on that line!
Live demo: http://jsfiddle.net/TvBeT/
Btw, document.domConfig is a property defined in the DOM Core spec.
None of the other browser define document.domConfig, so they return undefined.
More interesting, firefox 4 is the only browser that can run document.normalizeDocument(),
which method gives domConfig a value while it is running, merging adjacent text-nodes and adjusting the containment of bad html tags on an existing or newly created Document..
From the MDN page on domConfig:
This feature has been removed from the Web. Though some browsers may still support it, it is in the process of being dropped. Do not use it in old or new projects. Pages or Web apps using it may break at any time.
Is there an easy way to find parse errors in javascript code?
Last week I was debugging a javascript problem where the first javascript function that was called gave an 'object expected' error. I later determined that this was because the browser wasn't able to parse my javascript code. I eventually solved the problem but it was a painful process that involved pouring over my code line by line, trying to find my mistake.
There must be an easier way.
Use a tool like Jslint or an alternative browser.
Until recently, IE was the only browser that did not have built in development assistance. Other browsers will a) not come to a grinding halt on the first error they encounter, and b) tell you what and where the problem in your code is.
My favorite "quick ad easy" way to test IE syntax problems is to load the page up in Opera. It parses code like IE but will give you meaningful error messages.
I'll clarify with an example:
var foo = {
prop1 : 'value',
prop2 : 'value',
prop2 : 'value', // <-- the problem
};
If I remember correctly: In IE6 and IE7 the code will break because IE demands leaving the last comma out. The parser throws a fit and the browser simply stops. It may alert some errors but the line numbers (or even filenames) will not be reliable. Firefox and Safari, however, simply ignore the comma. Opera runs the code, but will print an error on the console indicating line number (and more).
Easiest way to write JavaScript is with Firefox + Firebug. Test with IE and have Opera tell you what is breaking when it does.
What browser are you using? IE8 has great build-in feature to debug javascript, for Firefox, Firebug is great.
Checking that the values passed into functions are correct and throwing your own errors if they aren't will help you track down problems faster.
Safari 4 (which runs on both Mac OS X and Windows) comes with some development tools (including a debugger) that are very useful. If you prefer using Firefox, Firebug provides similar functionality.
JSLint can help you track down simple errors.
Steve