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.
Related
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
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.
I think its the cause of trailing comma, or syntax error, variable used without declaration. My js fiel is 1000 lines od code. Since the error is not provding me the line no. Its becoming dfficult to debug. Please help me with debugging techniques for IE. The script works very well with Firefox, Safari.
I'd jslint the file. That will find the issue as well as any others you may have.
You can run it as a command line utility via node.
include this <script type="text/javascript" src="https://getfirebug.com/firebug-lite-debug.js"></script> and <html debug="true"> will give you an firebug console
http://getfirebug.com/firebuglite#Debug
For debugging in IE I would recommend you install DebugBar. This extension is similar to FireBug for Firefox.
If you are developing through Microsoft Visual Studio I remember it will help you find trailing commas by highlighting the following } element with a green curly underline.
If you use the built-in developer tools in IE8 and later, you can step through your code in the browser and determine which line causes the error - starting from the top.
If you are not using any debugging tools in IE, then I will advise you to - just like Johan and bjornd are suggesting.
Happy hunting :)
If you are using eclipse :
configure spket plug-in editor for java script
It will highlight the missing/incomplete syntax (e.g comma/semicolon)
so you don't need to debug for syntax errors
Guys, I finally did it ? I took the strength of all your techniques.
1) I put the code in a single
try{
code
}
and catch(e) {
alert('Final Err: '+ e.description);
}
and kept initial 200 lines uncommented and the rest commented and ran the file
while(EOF) {
if(got an alert of error)
checked for trailing commas & putting missed semicolons till end.
else
adding some more lines later uncommented out of the commented and ran the file.
}
Finally, the page got succesfully loaded !!!
I had this issue using the Extjs RowExpander user extension. The issue only occurred in IE. I was able to fix it by adding a few lines of code at the top of the 'toggleRow' method:
if (!this.view) {
this.bindView();
}
For some reason IE occasionally chokes on references to 'this.view' (likely a timing issue). Running 'bindview()' ensures that 'this.view' resolves appropriately.
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
Firebug is certainly a wonderful tool for javascript debugging; I use console.log() extensively.
I wanted to know if I can leave the Firebug-specific code in production.
What's the best practice? Commenting the debug code?
If you leave console.log() calls in your production code, then people visiting the site using Internet Explorer will have JavaScript errors. If those people have extra debugging tools configured, then they will see nasty dialog boxes or popups.
A quick search revealed this thread discussing methods to detect if the Firebug console exists: http://www.nabble.com/Re:-detect-firebug-existance-td19610337.html
been bitten by this before. Ideally all the console.log statements need to be removed before production, but this is error prone and developers invariably forget or only test in FF + Firebug.
A possible solution is to create a dummy console object if one isn't already defined.
if( typeof window.console == 'undefined'){
window.console = {
log:function(){}
};
}
One word of caution: It used to be the case for Safari on 10.4 that any call to console.log would throw a security exception as the console object is a reserved object used in the Mac OS Dashboard widgets. Not sure this is the case anymore, will check tonight.
Personally I modified my compressor a while ago to strip out console references pre-compress. A few minutes adding a regex there saves a lifetime of hassle.
Just thought I would add a really good tip for any js debugging.... use the keyword "debugger", and its like a breakpoint in the code, firebug detects it also MSIE (if you have visual studio) detects it and as I say its a breakpoint.
Not many people seem to know about this but I have found it invaluble... also if there isnt a debugger installed on the machine that is running the code, nothing happens and the code goes through fine. Although I wouldn't advise leaving them in there.
I have had many a headache caused by this.
I use console.log() a lot, and until recently, found that it would cause the entire JS code to fail in versions of FF not using firebug.
I usually run a find before going live, and commenting it out.
D
Some compressors will strip out any line prefixed by ;;; (which is a legal sequence to have, being three empty statements.) This way you're not strictly limited to console references (i.e. you could do some calculations and then console.log() the result at the end, and the compressor can strip all of them out.) I use JavaScript::Minifier for this.
I use this in OOP Javascript, making my own wrapper for log that checks that firebug exists:
myclass.prototype.log = function()
{
if( typeof window.console != 'undefined' )
{
console.log.apply( null, arguments );
}
}
Just call:
this.log( arg1, arg2, ...)
Just a reminder that IE Dev Tool does not support apply() on console.log.
Calling console.log.apply() will raise exception in IE8 when dev tool is active.
You can try JavaScript Debug, it is s simple wrapper for console.log
http://benalman.com/projects/javascript-debug-console-log/