Firebug causes Firefox to be unresponsive - javascript

I'm a beginner web developer. I often use Firebug to debug my JavaScript.
Problem is that there are some script files from my page's UI that have a lot of code and this causes my web browser to be unresponsive, i.e. I get a dialog saying the script is unresponsive. Basically this happens when I am within Firebug's Script panel.
How can I deal with this?

I tried finding solution to this problem and nothing.
As for the answer I think the best was posted by #Pablo(can't assign answer to comment unfortunately) and it is simply trying out Google Chrome console. None of the problems I mentioned exists here.
Cheers guys!

I have had the same problem debugging some of our older scripts that make extensive use of the eval() function.
This causes many scripts to be displayed within the Script Location Menu. (Each dynamically generated script is represented there.)
A possible solution, given that it was caused by the number of files in my instance, might be to see if you can bypass the problem entirely by utilizing fewer source files for the same code. Using a 'built' version of whatever frameworks you use might alleviate the problem. (Particularly if they still are debug-able in a built form.)
If that does not work, you might try debugging using Firefox' built-in debugger (available via Ctrl+Shift+S. (Or switch to another browser to do the debugging, but that is obviously a far less desirable solution.)

Related

Layout problems in CRM for Outlook

I just realized that what is a nice and working layout of a form with a webresource in on-line version, looses some (but not all) of the formatting when accessed via Outlook. It looks ugly and, I also get errors.
It's somehow related to the JavaScript added to the solution. Or, rather, the web resources, I'd say. Any suggestions on how to debug? F12 doesn't show the console when run from Outlook. I haven't done much with that version so any hint might be of help.
Are you able to narrow down your problem to a part of the script? Could you for instance disable and enable parts of the script(s) to see what works and what does not?
Since the layout is also being influenced, I think you are doing some (or a lot of?) DOM manipulation. This page on MSDN states:
HTML DOM manipulation is not supported
But there should not be that much of a problem (heard that one before...) using Outlook: Dynamics CRM 2011 Outlook client and browser rendering
Edit:
Just to prevent people overlooking the link to a related post from the comments: Random JavaScript Errors in CRM 2011 Outlook Client
Although the page you see in the CRM-Outlook is indeed rendered by IE, it's being served from another version of the engine than what is used to browse. During the rendition process it's "picturized" (lacking a better word for it) so what you see originates in a webpage but isn't one.
I don't think there's a way to debug that version. You can only rely that the development you've tested will work as supposed to. Note that there's no connected process of IE run at the same time as the Outlook client.
I'll gladly stand corrected but as far I've tried (and I've tried a lot, a lot), there's no way to get there.

Profiling JavaScript without crashing your browser

So tried my hand at profiling some code and I figured the easiest way to do it (at least on Firefox) was to use either console's time/timeEnd or profile/profileEnd, and I tried both.
The problem I have is with the number of runs I can do before Firefox crashes on me. Now I won't paste the code here because it's typical benchmarking code (and it's very messy), but obviously the gist of it is that it runs functions (a test is represented with a function), logging their execution time for a certain number of runs.
Now with for example, 5e4 it sorta works but I don't think it's enough to spot (very) micro optimizations, but more than that, it crashes.
So how do you profile your JavaScript? Because this way, it's barely feasible.
When I used to profile my JavaScript code I used Chrome's profiler; the JavaScript Console in the developer view gives it, and it pretty much worked for me. Have you ever tried it?
I have tried profiling a page with a lot of scripting in Firebug on FF4 and the same in Chrome (last version). Firefox crashed within a second or two, Chrome didn't seem to have problems with it. Maybe you can find something on it in the Firebug issues list?
Although not a traditional code profiler, I recommend Google's Speed Tracer:
Using Speed Tracer you are able to get a better picture of where time is being spent in your application. This includes problems caused by JavaScript parsing and execution, layout, CSS style recalculation and selector matching, DOM event handling, network resource loading, timer fires, XMLHttpRequest callbacks, painting, and more.
I think the profiler in the JavaScript Debugger (aka Venkman) is quite good. The version currently on addons.mozilla.org is not compatible with Firefox 4, but the change necessary to make it work has been committed. See https://bugzilla.mozilla.org/show_bug.cgi?id=614557 for details.
dynaTrace AJAX edition(free)- one more tool in your bag. Offers a little bit more detailed performance metrics, IMHO. They used to have it only for IE, but their new one supports FF too. Also see Steve Sounder's blog

Combining javascripts into a single file

Having read up recently on yahoo's web optimisation tips and using YSlow I've implemented a few of their ideas on one of my sites http://www.gwynfryncottages.com you can see the file here http://www.gwynfryncottages.com/js/gw-custom.js.
While this technique seems to work perfectly on most occasions, and really does speed up the site, but I do notice a significantly higher number of errors where the javascripts don't load or don't load completely while I'm working on the site so three questions:-
is combining scripts this way a good idea at all in terms of reliability?
is there any way to measure the number of errors i.e. the number of times the script failed to load?
is there any way to 'pre-load' the javascript or ensure that the number of loading errors is reduced?
Of course it's good. You will not only decrease HTTP requests but you will cut down delays in downloading other resources.
Try using minify: http://code.google.com/p/minify/, I've been using it and I've no complaints.
I can assure you that combining files WON'T cause any errors as a combined script is the same as 10 non-combined scripts, they all load in the same way (In an ordered way, left to right, top to bottom). Double check the way you're combining them.
Script execution stops at serious errors. If you have multiple scripts, the others will still run; if you packed everything into one big file, a lot more code won't get executed. So combining scripts is bad for reliability, but can be good for other purposes (mainly load time).
All browsers have some sort of javascript console which will show you the number of errors. Most have some sort of developer tool too (Firebug in Firefox, Dragonfly in Opera etc).
I'm not sure what you mean by preloading. Since a javascript file can affect the rest of the page in various ways, browsers will fully load and execute a script tag before continuing to parse the page (which is why scripts can slow page loading down so much).
I can't see the load function in your code which is being called on your body tag! I'd try and steer clear of adding JS to your HTML file, it can be added dynamically and will prob cause you less hassle along the way aas well as being easier to maintain.
I'd say that the things you need to look out for are making sure that you're not trying to call something before it's defined (maybe your seperate JS files were defined in a different order to how they appear in the single JS file).
Firebug for firefox is a good development tool, if you've not found it already. Webkit, Opera and IE also have various other dev tools.
Combining JavaScript files is always the best way to go, unless it's not logically sane to do so (downloading jQuery from Google Code instead of hosting it yourself is a good example).
I always combine as many files as I can (JavaScript, CSS, images (CSS Sprites), etc.), also in development, and I never experience any problems. It's way faster regarding less http connections, which should not in any case be underestimated.
Regarding that you want to count the errors, I don't exactly see what you mean. But, debugging tools like the built in one in Google Chrome or Firebug for Firefox are good tools for debugging your JavaScript code, and shows lists of the errors occurring.
And to that thing of preloading: Yes, it can be done, though it'll become nasty and illogical. However, I can't think of any case whatsoever where it would be a good solution to have the trouble to preload the JavaScript, compared to just make it work right out of the box, no error checking needed.
About the error you are experiencing, the only one that my Chrome points out is this:
Uncaught ReferenceError: load is not defined
... which seems to be the onload method "load()" set on line 55 of your HTML document when the body tag is started.

Getting very strange javascript error and this page also refuses to work in Internet Explorer 7 or 8

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.

Using Firebug Lite (1.2) would you use it in production sites?

I tried to use Firebug Lite (via the bookmarklet and also adding it to one of my web sites).
I seem to get the alert:
Unable to detect the following script "firebug-lite.js" ... if the
script has been renamed then please set the value of
firebug.env.liteFilename to reflect this change
Alot. Especially when I try to close the tab. This happens in Firefox, Camino and Safari.
What I'm wondering is, is this ready for use?, or do I need to copy the code, post it locally and hack it? I already checked the documentation, and it was pretty limited.
I was also looking at the mod dates and the site appears to have been relatively idle since mid-2008.
The javascript file rounds out at 77,305 bytes, so I would think you would not want to use it on a production site unless you were using a dynamic language and could output the script conditionally when you need to do debugging.
(i.e. http://www.somefakesite.com/page?debug=true)
As long as you're only including the file in the page when you are actually debugging, it probably doesn't matter where you pull the script from unless it doesn't work correctly, in which case you would have to modify and serve it yourself.

Categories