I expect this might get some downvotes / closevotes but I'm going to ask anyway as I can't find an answer to this anywhere else, and I know that others who use Firebug on a daily basis must have noticed this too.
When I hit many "big" sites, such as Google, Paypal, Wordpress sites (especially the admin interface after a couple of plugins are active) and others with Firebug active, it can break on atleast 2-3 errors per page request. Normally it's undefined variables or something along those lines, quite often in jQuery (although what caused that error isn't).
This is very annoying >:( and much more frequent than I remember even a year ago. It happens alot on websites that you would expect to be well checked for script errors which is what I find to be the most puzzling - whenever Firebug reports an error on one of my sites, I fix it until none show up, ever. What's the difference here?
What I want to know is this: has firebug's error detection gotten alot stricter recently or have the general standards of script coding gotten worse - or a mix of both?
Or am I just being an idiot and have switched on super-uber-mega-strict error checking somehow?
Using Firebug 1.9.1 with Firefox 11.0 on Max OSX Lion.
the kind of thing I see more times a day than I should in a month:
p.s error is a is null, somewhere in the jQuery source.
You've stumbled on the fact that many big websites are badly coded.
Related
I'm debugging a WebGL application, and the following error message pops up in my console, right after a call to compileShader() and getShaderInfoLog():
GL_INVALID_OPERATION : glGenSyncTokenCHROMIUM: fence sync must be flushed before generating sync token
I've searched teh interwebs for glGenSyncTokenCHROMIUM, with no avail.
(This error seems to be hardware-specific, as I can only reproduce it on a GT-I9505 when running Chrome)
What does this error mean, and/or how can I get more detailed information of what's going on?
It seems to be indeed device/GPU/driver problem. There's bug in Chromium bug tracker (by the way, you can provide your case to it).
There're several ways to get information and help on WebGL bugs. Besides StackOverflow, there is WebGL google group (browser developers also active in it). Bugtrackers may be helpful (you always can and should report bugs to developers). And, if you feel like it, Chrome and Firefox have excellent code search engines (ff, cr), more than once I've found answers to my questions there.
I'm trying to get an angular.js/jQuery app running in IE8. I mostly have things working, but it spews a lot of console errors:
TypeError: 'undefined' is null or not an object
These errors in the developer tools don't have a source location (file & line) associated with them, and the debugger doesn't break on errors when these are being thrown, even if "Break on Error" is enabled.
Other than disabling portions of my code to search for the cause, is there any way to figure out where this is coming from? I'm getting dozens of them in every Angular digest cycle, so it's not as straightforward as figuring out what page actions cause them.
It's not obvious what, if anything, they're breaking on the page, but I haven't yet had the ability to test the whole thing, so it's hard to conclude they're benign; even if they are, I'd prefer to get rid of them; they're noisy and I'm concerned that they may be visible to the user under some IE error-handling configurations.
Though I've never used it, I've heard that DebugBar is an improvement over the standard IE8 developer tools.
Also, as JJZabkar mentioned in the question comments, Angular versions below 1.3 require certain shims to be in place to work with IE8 or below.
Another thing to be aware of, which is also described at that link he provided (https://docs.angularjs.org/guide/ie), is IE8's lack of support for custom element tags, which will foil any use of element-based directives (possibly causing errors) if you do not take certain measures.
I've downloaded the latest version of IE9 beta and my site wrecks it. No problems on any other browser, but on IE9 it freezes on every page. The thing is, many other sites also make it gag.
Should I worry?
IE's fault or do my site and I need to do some serious soul searching?
How does one debug this stuff and are there a list of common culprits? Is it most likely a Javascript issue? jQuery?
If your site is dying on IE9 (assuming it's not the result of known IE9 bugs), you definitely need to address it. You can download tools like the IE Developer Toolbar to help you move about within your page once it's loaded, and there are other resources online like jslint that will help you examine some of your javascript and work on its quality.
If you find any specific issues that you're unsure of how to address, please don't hesitate to return here and post more questions - there are (literally) thousands upon thousands of brilliant minds waiting to assist you.
Update - You mentioned in the comments below that IE9 dies before you can even determine what is causing it to die. This is (unfortunately) the case with much software. Often times you can try to repeat the same actions in Chrome, Firefox, Opera or some other browser and see how it responds. Many times you'll find that another browser may provide an error without crashing entirely. This could give you some insight into what may be causing IE to crash.
Jonathan submitted a great answer about using jslint to verify the integrity of the JavaScript, and using other debug tools on other browsers to detect for a non-crash error. I did both and thoroughly went through my site, only to find that IE9 was still crashing!
So I looked into it and here's what I found: the main cause of IE9 beta crashes are add-ons that are incompatible with the new release. Adobe PDF viewers, printer add-ons, toolbars, etc. Most everyone has at least one add-on in their browsers. So I disabled all my add-ons and now my site works.
I'm not sure why my site seemed to crash more than others with IE9, but if people are having problems with there site, I'd suggest (1) disabling all add-ons just in case, and then (2) using Jonathan's answer (which I'll leave checked as the official answer since it has to do more with programming).
This is the page I'm working on... http://schnell.dreamhosters.com/folio/earthquake.html
Its purpose is explained via the instructions on the left. I'm finding that after doing so many searches and clicking so many of the links in the list on the right that the page freezes up, the Google Map stops working and Firebug tells me of an error in main.js and it goes like this...
b is undefined
Line 49
I really don't know why this decided to happen all of a sudden and the error is so cryptic and muddled amongst Google's code that I don't think I'll be able to figure this one out by myself.
Another problem I'm finding is that the page itself simply refuses to work in IE7 and IE8 (or probably any version of IE for that matter). I am also at a loss as to how to solve this problem because I can't figure out how to use any of IE's debuggers (if they even have one) and seeing how I already tested this and made it work in two browsers (technically three since Safari runs off WebKit just like Chrome), I just don't have the drive or capacity to imagine what could be going wrong.
Any help would be greatly appreciated
Moved from comment to answer.
As scunliffe mentioned, you are trying to do a crossbrowser AJAX without using jsonp. Use either $.ajax() with datatype jsonp or add a &callback=? at the end of the URL in the $.getJSON() call.
IE8 is quite good when it comes to helping out the developer. From memory F12 will open up the developer window where you can inspect the DOM, CSS and debug script.
Your error is cryptic because most javascript comes minified, so variables are all remapped to single letters, etc. See if the script causing the problem has a development (i.e. unminified) version as this will make a lot more sense to step through.
With regards to your specific issue it sounds like a timing issue. While browsers do a decent job of executing script in a consistent way if you follow standards, they do differ in their timings i.e. when things execute. That would explain why b is undefined in some cases and not others.
Working with Extjs, GeoExt and OpenLayers, I more and more tend to run into problems which do not result in direct javascript errors (in either IE, FF or similar). It could be features not working, unexpected behaviour and so on.
My usual strategy is to strip down code to a minimum hoping to discover where the problem arises - Firebug and the IE debug tool are usually great companions. Google and various forums are always a big help – IF a similar problem has been documented by another user and IF the problem has been formulated in a way so that I find it.
But when it comes to using larger frameworks such as Extjs and OpenLayers, I find it very difficult when my debugging leads me inside the frameworks world of mysterious methods.
Asking questions here and in other forums can give fantastic results, but sometimes I cannot point to what the problem actually is – only the result I see on the screen. Using multiple frameworks it could be interference between them, unexpected behaviour when using exactly those frameworks and generally just complicating the debugging.
What do you recommend I do in these situations? What do you normally do – I would love to pick up a trick or two :)
I feel your pain. I use YUI a lot and sometimes errors get sucked into a bottomless pit of YUI code that doesn't generate an error per se but also doesn't do what I think it should.
In cases where I'm lucky enough that an error is thrown inside foreign code I look at Firebug's call stack and start debugging at the first place up the chain where I find my own code.
In the case of the bottomless pit swallowing errors then I resort to setting breakpoints in my code at suspicious places and single-step my way through.
Firebug is very, very useful here since it allows you to dynamically set breakpoints and conditional breakpoints. In both cases above I never reduce my problem to a minimum because the bug may be due to the complexity. Also, setting breakpoints is much easier.
About the only time I reduce my problems to a minimum is when I need to post it here or at comp.lang.javascript.
Now, if the bug only appears in IE I usually give up for the day, go home and come back tomorrow. It is a surprisingly effective strategy until my boss decides that we need to push the code to live TONIGHT (in which case I just cry inside).