Sencha Inc. | HTML5 Apps

Debugging Ext JS applications

Published Sep 17, 2010 | The Sencha Dev Team | FAQ | Medium
Last Updated Jul 11, 2011

This FAQ is most relevant to Ext JS, any version.

This article is currently due for review
We suspect that this article may be out-of-date or contain incorrect information.
But we are constantly editing articles, so we promise we will get to this one soon.

Whether you're a seasoned JavaScript programmer or just starting out, the cause of problems can often be hard to track down. Here is a checklist you can work through when your code is not working as you expect it to work:

Read API Docs

  • If you're using released code, read the API documentation. This covers all the ExtJS classes, methods, config options etc. and includes interactive examples that you can learn from.
  • If you're using pre-release code (beta or alpha code) the functionality that you were used to in a previous version may have changed and the new documentation for that code may not yet be complete. In that case, you may need to jump into the Ext code and see what it's doing firsthand. Using a debugger will make understanding the ExtJS library code much easier.

Double-check the simple things

  1. Are all the proper script files included AND in the correct order?
  2. Check syntax using or a good IDE
  3. Check your code and XHR responses for trailing commas in Internet Explorer
  4. Did you misspell your object / method name?
  5. Make sure that you don't have any extra whitespace (like carriage returns or line feeds) between the return statement and the first opening curly brace ( { ) or it will always return null. For example, the wrong way:
var myExample = function()
        foo: 'bar',
        boo: 'far'

Be sure the opening curly brace is on the same line:

var myExample = function() {
    return {
        foo: 'bar',
        boo: 'far'

If not, it'll be a pain to debug as trying to reference '' or '' will result in an error that they're undefined even though it seems they clearly are.

Include uncompressed source files

  • Including ext-all.js is the preferred method for 'final' deployment.
        <!-- ** Javascript ** -->
        <!-- base library -->
        <script type="text/javascript" src="../../adapter/ext/ext-base.js"></script>
        <script type="text/javascript" src="../../ext-all.js"></script>
  • Stick with ext-all-debug.js during 'development' so that variable names will be meaningful and you can step through the code on errors.
        <!-- ** Javascript ** -->
        <!-- base library -->
        <script type="text/javascript" src="../../adapter/ext/ext-base.js"></script>
        <script type="text/javascript" src="../../ext-all-debug.js"></script>
  • Note: to obtain the equivalent of an uncompressed ext-base.js, simply include the file /source/core/Ext.js followed by /source/adapter/ext-base.js (found in the official download)

Add some error-handling

If you are getting a generic or vague error message, the actual error may be getting swallowed at a lower level -- this can happen frequently in ajax callbacks as YUI's ConnectionManager purposefully swallows errors if you don't use the debug version, so any error even in your callback, gets lost. If you know generally where the error is happening, try adding a try...catch block around it and see if that helps identify the issue.

Use a debugger

A good debugger will allow you to easily see where the error is occurring, step through code, inspect in real time, etc. There are many options for debugging:


  • Probably one of the best tool combinations for debugging your application is to use the Mozilla Firefox browser with the Firebug addon and optionally the Web Developer addon.
  • See Firebug Docs
  • Firebug integrates with Firefox to put a wealth of web development tools at your fingertips while you browse. You can edit, debug, and monitor CSS, HTML, and JavaScript live in any web page.
  • Set a break point at some point in your script, reload your page, and see what your values and objects are at runtime. You 'will' figure out the issue much faster than making trial and error changes to your code (or adding alerts!).

  • Once you set a breakpoint you can inspect exactly what arguments/objects are available and drill down into the objects to see what properties and methods are available.
  • Break on All Errors. Sometimes an error will bubble up to the top of your application and it's almost impossible to figure out where it's originating from. When the Script tab in Firebug is active, the Options dropdown contains the choice "Break on All Errors." If you enable this option, then Firebug will pause on the exact line where the error occurred as soon as it happens so that you can inspect the code and the current stack trace.

  • 'Don't use "alerts" '. Use the console (, console.dir, etc) to output valuable information to the firebug console.
  • You can also use Firebug to inspect the DOM to figure out exactly which CSS classes are being used on which DOM elements and alter them on the spot.


Using Firebug's console with other browsers


Internet Explorer

Is the dreaded IE giving you fits:

  1. Trailing Commas!
    1. Check your javascript files
    2. and any XHR responses for trailing commas using good IDE, jslint, or json formatter and validator.
  2. Look for a typo in your actual HTML. Check for invalid closing tags (title or script tag is not properly closed, etc).
  3. Check your problem in another browser that has better debugging utilities available (ie. Firefox). The other browsers may reveal something.
  4. Check memory leaks

Still can't figure out, try one of these:

  • IE8 has debugging support built in similar to firebug
  • There is a free edition of Visual Studio (Visual Web Developer 2008). It is a huge download (like 2gb) but it is an effective JS debugger. Check out this blog entry.
  • DebugBar and Companion.js
    • DOM Inspector: View DOM Tree and modify tags attributes and css attributes on the fly to test your page
    • HTTP Inspector: View HTTP/S request to check cookies, GET and POST parameters, view server info
    • Javascript Inspector and Javascript Console: View javascript functions for easier debugging, see Javascript and AJAX code
    • HTML Validator: Validate HTML code to correct and optimize your code and html size of your page
    • And many more features: See page cookies, get pixel color on a page, make a page screenshot...
  • httpWatch
  • Firebug Lite
  • Microsoft Developer Toolbar plugin.
  • For exploring the DOM and other niceties: IE Web Developper. IE WebDeveloper is an add-on for Microsoft Internet Explorer. The rich web debugging toolset allows you to inspect and edit the live HTML DOM and current cascaded styles, evaluate expressions and display error messages, log messages, explore source code of webpage and monitor DHTML Event and HTTP Traffic.
  • For getting the right file and line number info of JS errors: MS Script Editor
  • Venkman, Visual Studio, MS Script Debugger



Other Tools

  • Fiddler. Fiddler is a HTTP Debugging Proxy which logs all HTTP traffic between your computer and the Internet. Fiddler allows you to inspect all HTTP Traffic, set breakpoints, and "fiddle" with incoming or outgoing data. Fiddler includes a powerful event-based scripting subsystem, and can be extended using any .NET language.
  • JSlint can help find errors and clean up your code.
  • YSlow. YSlow analyzes web pages and tells you why they're slow based on the rules for high performance web sites. YSlow is a Firefox add-on integrated with the popular Firebug web development tool. YSlow gives you:
    • Performance report card
    • HTTP/HTML summary
    • List of components in the page

Still haven't figured it out? The Forum Guide

  • 'After' you read the Help Forum Guide please feel free to post to the ExtJS Help Forum.
Share this post:
Leave a reply

Written by The Sencha Dev Team

1 Comment

Steven Roussey

4 years ago

Illuminations is a plugin for Firebug that make Firebug understand ExtJS natively:

Leave a comment:

Commenting is not available in this channel entry.