Tuesday, February 6, 2007

My Favorite Browser Based Development Tools for Internet Explorer

If you aren't using browser based development tools to help with your web application development, it is time to start. With Ajax enabled sites becoming common, View Source is no longer a reliable debugging approach. Also, when looking into issues like Cross Site Scripting (XSS), it is useful to have an embedded HTTP monitor. Firefox users seem to have universally adopted Firebug, but what about Internet Explorer? I personally use two IE tools, IE Developer Toolbar and IE HTTP Analyzer, and this blog explains why they are useful.

NOTE: this blog entry was originally posted February 7th, 2007 on my previous blogging system (dev2dev.bea.com).

My Toolbox

This blog discusses the browser based tools I use for troubleshooting and debugging in the web world. Every developer has their likes and dislikes when it comes to the tools they use. Discussions that compare and contrast different development tools like IDEs often degrade into religious tirades. I am not asserting that my toolbox is necessarily the best - it's simply what I use and what I like. Please add comments to this blog entry if you have found other tools useful. This blog will explain the capabilities that I use with these tools, but I will not cover all of the features.

Both of these tools are client side solutions, and install directly into Internet Explorer. I like the convenience of these features being one click away as I am working with a page. I personally use IE 7, but both of these tools work with IE 6 as well.

IE Developer Toolbar by Microsoft

The IE Developer Toolbar is a free download that snaps into your IE browser. By default, the tool pane is hidden from view. When you want to use the tool, you click on one of the options in the menu toolbar. This tool is great for debugging page content issues.

IE HTTP Analyzer by IEInspector Software LLC

The IE HTTP Analyzer is a modestly priced download that snaps into your IE browser. By default, the tool pane is hidden from view. When you want to use the tool, you click on the small icon to the right of your Page/Tools dropdown. This tool allows you to inspect all aspects of the HTTP protocol as your browser makes requests.

The rest of this blog will describe some use cases for which I have found these tools very helpful.

Use Case 1: Page Inspection - Viewing the Current DOM

Tool of Choice: IE Developer Toolbar

The View Source feature on browsers has no small place in the history of the web. How many people first learned HTML from a book? I, like most other developers, learned HTML using the View Source feature. The rapid expansion of the web back in the 90's was probably helped tremendously by this browser feature.

The View Source feature also used to be a great debugging tool while developing dynamic web projects. JSP not rendering correctly? View Source to the rescue. However, while View Source still has some use, it is no longer a reliable tool to help your development efforts.

Today's websites are far more interactive than the pages of just a few years ago. By way of DHTML and/or Ajax, the HTML that came back from the last page request may not be what the user is currently seeing. As you likely know, parts of the page DOM may get updated as you work within the page. View Source unfortunately is not tuned into this: it will only provide the HTML from the last page load.

Fortunately, the IE Developer Toolbar can help here. It has a View DOM capability that enables the developer to inspect the current state of the DOM for the page. When enabled, the tool will create a new window pane at the bottom of your browser that will show the DOM tree. For each node in the tree, you can inspect its style attributes and text children. As dynamic page capabilities change the DOM, the tree will be updated to reflect the changes. Also, a handy feature is the "Find by Click" capability. This enables you to navigate the tree by clicking anywhere on the page, and the DOM viewer tree will find the element you clicked on.

For example, WebLogic Portal 9.2 can make any portlet Ajax enabled. This prevents clicks within the portlet from causing page refreshes - it will update only the portlet instead. To capture the returned HTML from a portlet update, View Source will do no good. View DOM is the way to go.

Use Case 2: CSS Debug - Why is that text green?

Tool of Choice: IE Developer Toolbar

Cascading Style Sheets (CSS) allow for sophisticated page styles, but come at a price. At times it can be difficult to pinpoint why a style has been applied to an element on the page. Have you ever had trouble determining why a piece of text is a certain color? Or why the font is not what you expected?

WebLogic Portal has a sophisticated Look and Feel capability that allows developers to fine tune the appearance of a portal page. Styles can be associated with page tabs, portlet headers, portlet backgrounds, menus, and many other things. When I work on a Look and Feel, sometimes I need a little help to make things look right.

The tool that I find most useful is once again the IE Developer Toolbar. The DOM inspector allows me to click anywhere in the tree, and look at the applied styles. Then, I can walk the tree upwards until I discover which class the style is coming from. Because this is done in the browser on a rendered page, it is a very accurate and quick approach.

Use Case 3 - Monitoring Requests: Performance and Security Aids

Tool of Choice: IE HTTP Analyzer

Performance

While there are many useful server-side performance tools available, it is still helpful to have a client side tool. There are several scenarios that can be seen on the client:

  • Too many artifact requests - a single page may use hundreds of images/css/js files
  • Big artifacts - images/css files may be abnormally sized
  • Too many XmlHttpRequests - Ajax gone wild can overload the server

The IE HTTP Analyzer when enabled appears in a pane at the bottom of the browser. The top section of the tool shows the list of requests that the browser has issued. With each request, it shows the size in bytes of the response, the response time, and other attributes. With this feature, the above performance concerns can be quickly identified.

Security

Cross Site Scripting (XSS) testing has become an important part of the QA cycle when developing web applications. The typical behavior of a XSS attack is that it will send rogue requests to malicious systems from your browser. I recently wrote a blog entry about a specific XSS vulnerability with PDF files. While I was exploring that issue, it was useful to be able to see those rogue requests being emitted.

I found that the request monitoring feature of IE HTTP Analyzer to be useful in this case. It allowed me to easily see the problem, and validate that the solution that I implemented was sound. For security testers and for developers working on XSS issues, I think this tool is quite helpful.

Use Case 4: HTTP Headers - Viewing and Setting

Tool of Choice: IE HTTP Analyzer

Viewing

Request/response headers are a cornerstone of the HTTP protocol. Every request and response have them, and the information contained within is quite important. Cookies, caching, browser specific HTML, language detection - headers make these features possible. With any feature, sometimes things just don't work correctly.

IE HTTP Analyzer allows you to view the request and response headers for each request. This can be enormously useful when troubleshooting problems related to the headers. This week it helped me diagnose an issue with an incorrect mime type being returned for a resource.

Setting

There are cases when being able to view the headers is not enough. I recently did a blog post about implementing Single Sign On (SSO) with WebLogic Portal. The solution required a server side component to detect a special token in the request headers that contained the user identity. In a production environment, a proxy server would do the job of inserting the header. But while developing the solution, I wanted an easy way to test the implementation.

Once again, the IE HTTP Analyzer gave me a great solution. The tool provides an easy way to clone a request, and then muck with the request headers. In my case, I needed to clone a request to my WLP instance, and then add a test SSO token to the request header. The Request Builder can then rerun the request with the new header, providing a very easy way to test my implementation. See the image below on the tool in action - notice the new header I added (text selected).

Additional Resources

Browser Tools

Online Tools
These are convenient, but only work for testing internet accessible web servers.
Note: these are proxies hosted by 3rd parties, it probably isn't wise to login to your bank through them.

WebLogic Portal

Technorati Tags: ,,,
Posted by at
Labels: , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)