So, I have a large project with a bunch of javascript stuff going on.
Now I did some testing with IE9 and on one event triggered AJAX-operation it aborts and tells me
Syntax Error: Expected ')'
but that's all it says. It leaves me without any clue about where to start looking.
I'm using Dojo for most of the things I do and at this particular point I'm retrieving JSON-data with the AJAX-request. But I've ruled out an error in the JSON-string, simply because JSON ususally does not contain brackets (), right?
There also is a console.log(data) right after the request should be completed, but it doesn't fire either. And I don't see any fancy bracketwork before that, that could make IE lose it's mind. But I might still be looking at the wrong spot, just trying to give as much info as possible here.
(btw: Firefox is fine with everything. No errors or warnings; everything runs just fine)
What's the best way to debug this or possible causes?
Versions of Internet Explorer from 8 upwards have a built in debugger which is similar to Firebug - press F12 to launch it (by default).
The standard error reporting is terrible, but the debugger will give you much more accurate feedback on where the error occurred.
(My take on this is that the standard Javascript error handling assumes you're a typical IE user and gives you very little feedback. Firing up the dev tools lets it know you can handle the truth.)
It was the response from AJAX after all.
IE had problems sending all the GET parameters resulting in an error message being mixed with the JSON code. I still don't understand why it expected a ) but fixing the response fixed the issue.
Related
I'm getting this error message intermittently within a relatively large project at seemingly arbitrary times (which makes me suspect a race condition somewhere...), so I unfortunately don't have a minimal example illustrating this problem as I do not understand the root cause. Basically, sometimes I get an error signal where event.target.webkitErrorMessage is "Internal error checking key existence". But I don't really understand what this error message is even supposed to mean.
Googling for this phrase returns only 7 results (although it will be more once Google and others find this question). These results are all either Chromium source code or bug reports about adding more detailed error messages to Chromium. As I am not intimately familiar with Chromium's IndexedDB backend implementation, one thing I'm struggling to understand is what this error message means in terms of frontend JavaScript code. For instance, what kinds of JavaScript mistakes can lead to that error message?
The code in question seems to work fine in Firefox, FWIW.
EDITS BELOW
I also, more rarely, get null returned as a cursor in response to an openCursor request for a key that I know is a real key. This is also inconsistent - it happens for different keys and rarely. And it's also only in Chrome. Very bizarre.
And I'm not sure if it's relevant, but this all happens within a large transaction with many updates in two object stores (these are the ones leading to the null openCursor problems) and many adds in another object store (this seems to be the source of the "Internal error checking key existence" error). I will try to make a minimal example of this and investigate further, but regardless of how that turns out, I'd still like to know the answer to my original question, which is what specifically "Internal error checking key existence" means.
ANOTHER EDIT
After playing around some more, I ran into another weird transient error message, "Internal error: backing store error performing put/add". I'd also be curious about what that implies about my JavaScript.
Also, I validated that all of these problems are new to Chrome 26 (and remain in Chrome 27). Downgrading to Chrome 25 makes all these problems disappear... so maybe this is all just from some bug in Chrome...
ONE MORE EDIT
All of these problems seem to only happen in Linux (I'm using Ubuntu 12.10). In a Windows XP VM with Chrome 26, I can't reproduce any of these errors. I submitted a bug report as it's becoming increasingly clear that this is all due to some bug, but I'm not sure if I've narrowed down the issue enough to help find a solution.
As I mentioned in an edit to the question, I submitted a bug report. It has seemingly been resolved in Chrome 28. So anyone experiencing this problem in older versions of Chrome, just upgrade to the unstable version or wait a couple months for Chrome 28 to be stable. And if anyone gets errors like this in Chrome 28 or higher, it's likely a bug.
Let me start off by saying I realize that this is a long shot. I've spent about 7 hours on this already making zero progress or finding any leads. Debugging in IE6 is no fun.
I have implemented the tineMCE editor spellcheck pluging using ASP.NET, following instructions on this page: http://www.kelvinluck.com/2009/01/using-spell-checker-for-tinymce-with-net-on-iis/
Everything works in IE8, Firefox, Chrome, etc
IE6, however, hangs up once the spell check button is pressed (only when spelling errors are found).
At this point it just spins the ajax indicator forever.
I have used fiddler to compare the ajax calls with the ie8 version which is working great. There is no difference in the POST or the response. It generates the response with all the bad words identified in both versions.
I have used debugBar to check for errors, what I get is "Invalid Argument", but the line number is always different and in the high millions, typically, which is very weird (this might be because I'm using IE Tester).
I realize this is the kind of question nobody likes, but I'm pretty much out of options, and I need to get this to work in IE6, as this is what our client regretfully uses. I'd be very interested in hearing about some potential debugging methods for IE6 or details regarding tinyMCE's spellchecker plugin.
The Microsoft Script Debugger is much more reliable than IETester. Here's some tips to work with it:
If you get an error alert, view source and copy it to a text editor. Find the line number and look before and after it for a syntax errror, such as a hanging comma, missing semicolon, or missing parentheses.
To prevent breaking on an error, unset the Break on Error toggle button or press Ctrl+Shift+E.
If you want execution to pause at that breakpoint only when a certain condition is true, then set a condition for that breakpoint. To set a breakpoint Condition, right-click on the breakpoint, select the Condition... option, enter the condition and click OK
Use Fiddler for troubleshooting network response issues, and the JScript Error Reference to help identify the specific error message.
I'm developing in Javascript for quite a long time now. Usually when I hit an error in IE I know roughly where it originated even if the message received from IE is useless bunch of text. When I don't know where the error originated, I usually try to "delete" parts of my code, until the error doesn't repeat itself, and that start manually checking line by line until I find the error.
I'm sure that it's far from the best approach, so I'd like to ask you how you debug error like these:
If you are using IE8+, you can press F12 on a page to open the Developers Tools.
This contains a JavaScript debugger, much like Firebug & Chrome Dev Tools
EDIT:
In response to the comment under the question, if IE is throwing a cryptic error that you are unsure of, there is a couple of steps I would do.
Is it an IE only error? Does the same error occur in Firefox? Chrome?
Is the error occurring in a 3rd party library. If you believe it is, use an un-minified version of the library.
Can you replicate the error outside of your website? Can you make the error occur in a http://jsfiddle.net/ for instance?
If you still can't narrow down the issue, post a question on SO with your code, any error messages, and expectations of the result.
HTH
Try using non-minified version of jQuery - it will give you a better idea where exactly the error is. Also, if you use VS 2010 to debug your js code in IE, it will break at the error line. This always works fine for me.
IE is the only browser that I've managed to successfully use the fantastic Visual Studio script debugger with - in my experience Visual Studio is hands down the best script debugger out there, so quite often I find myself in the reverse situation to you (running broken scripts in IE just so I can use the script debugger)
See How to debug JavaScript in Internet Explorer for instructions on how to use Visual Studio Express to debug scripts in IE - if you own a full edition of Visual Studio then its much simpler (just attach to IE as normal).
Why some javascript error only comes in IE not in firefox? should i solve all IE javascript errors, if my site is working fine with it ?
You should definitely seek to fix any JS errors you are getting in IE. What shows up in your IE as a little yellow icon, will show up in other IE browsers as a popup letting the user know there was an error.
One way you can minimize problems is by using one of the many JavaScript framework/libraries like jQuery, MooTools, etc that seek to minimize browser differences. Then, when you get specific errors, they can often be fixed by added a missing ; or adding an if statement in the correct place.
You should never knowingly leave code unfixed that is known to break in modern browsers.
should i solve all IE javascript
errors, if my site is working fine
with it ?
I'd say, yes absolutely. Under certain circumstances, IE throws Javascript errors right into the user's face with a big fat dialog. I think it's very embarrassing for a visitor (who may not even know what JS is, and even less the intricacies of cross-browser scripting) to get a error message as their first impression of you.
they have slightly different implementations of javascript, dom, css, etc.... should you fix the errors? if no major functionality is impacted, then it would probably be a very low priority... and depending on your userbase (say its a corporate intranet) you could simply say Firefox is your preferred browser. all depends on the requirements. Prioritizing tasks will help ensure the most important objectives are met.
Yes, you should fix the Javascript errors being reported in IE, because it can be unclear how the errors manifest themselves in your application. For instance, it can cause menu navigation to not work, or incorrect behavior of buttons.
As for actually detecting where the problem came from and how to fix it, you can try our Browsera service, which will detect and log the Javascript errors for you that occur in the browser, and use the Script Editor, which comes with MS Office
Or, if you dont have OFfice, use the free Microsoft Script Debugger, which works, but is less powerful.
if you are working with ajax than you can use $.getJason using jQuery, instead you get data from ajax and then use JSON.parse();
I have a big (probably) javascript problem.
i have a long and complex script on the page based on mootools framework,
in FF and other browser everything works fine, but in ie 6 and 7 i got "error:153 (sometimes 84) Unspecified error" and the strange thing is in IE8 that show me the error "Object doesn't support this property or method".
someone know the possible cause of the problem? o maybe someone know a list of IE's unsupported property or method?
In IE8 you can get the line number of the error, then right-click -> view source. IE8 has a proper source, which includes script lines, so you should quickly be able to find the source of your error.
If the script you're using isn't obfuscated or all on one line, you could use the JavaScript debugger in IE8 to pinpoint the object which is causing the error. Press F12 to open the Developer Tools, go to the Script tab, and click the "Start Debugging" option. If there's an error it may well break on the relevant line. If not you can set some breakpoints and step through the code.
You can also use IE8 developer tools http://blogs.msdn.com/ie/archive/2008/09/03/developer-tools-in-internet-explorer-8-beta-2.aspx to debug.
For other version I suggest you use Web developer tool bar which is similar to web developer tool bar for firefox.
Its near impossible to tell what the problem is with this information (at least for me).
For IE6/7 I suggest adding a few alerts to the javascript in intervals to find out exactly what line of code is causing your problem. If you know which object is causing the error, it is usually quite simple to find out what the exact problem is.
IE8 provides nice debugging tools, so that is a good place to start.
In my case the error was due to a $ mapping conflict.
Using jQuery instead of $ solved the issue.