Monthly Archives: March 2010

Tutorial: Using IE Developer Tools as Firebug in Mozilla Firefox

There was a time when development for Javascript and CSS was restricted mainly because IE was the only main browser around (basically because it was shipped with your copy of MS Windows) and even the other browsers like Opera and Netscape were not able to listen to the web developer needs. Then came around, Youtube, GMail, Facebook, all of them giving rise to the concept of RIA (Rich Internet Applications) and at the same time Firefox was launched (2004). Firefox was an open source project which in turn allowed thousands of developers around to write what they want as plugins and someone came up with the idea of Firebug, that bug caught the web development community like fire and this plugin has more than 117,085 weekly downloads at the time of this writing. If  you ask any web developer that which plugin is his/her favourite, firebug will always get mentioned at the top and due to all good reasons. I remember coding Javascript before the firebug, when to check and debug a javascript array, I would have to write alert(array.length) and that will pop-up an alert box with array length and then imagine my page is getting updated after 1 second or that array is in a function who is running in loop.. bang! … just to inspect an instruction in that loop, that alert box will appear after every 1 second and ultimately I would have to kill my browser to get rid of it. Not the case any more. Then came around Ajax, I remember JS frameworks such as YUI and jQuery weren’t around in those days and I wrote my first function to make an Ajax request using XMLHttpRequest and after that telling my colleagues that the problem in writing Ajax code is that, you don’t get to see what is happening behind the request. A real nightmare? well we are lucky now, that dark period for client-side web scripting is over.

I don’t think if you are a web developer and you are not aware of firebug but this can be the case that you are a web developer and you are still sticking with the Firefox just because you love firebug and web developer toolbar. Most non-techie people around the globe still love IE (some of them are still on IE6 because that came with their MS Windows XP installation) and they constitute more than 70% of  the total, so if you are going to develop for general public or for a client who just couldn’t understand that why I don’t use IE and why Firefox is my favorite browser, you need to have a look at your web application in IE before shipping it and I am telling you it could always go wrong as you may be calling a function whose one parameter Firefox is ignoring and still executing the code while IE wouldn’t ignore and will stall altogether. Luckily, IE8 comes bundled with IE developer tools (developer tools were around from some time but installing them on and off was a real nightmare, at-least for me). But yes I can hear what you are saying, most of the times, IE will throw an error and it will have very “helpful” error description such as “Unspecified Error” and it will point at totally wrong line in the source code and you will have to do your guess work to eliminate the problem, anyway, with developer tools you could see something in place of nothing.

Enough discussion, here is your 3-minutes crack-on graphical tutorial to use IE developer tools just like your native firebug console and web developer toolbar on Firefox.

First load your desired web page in IE8 which you want to inspect by pressing F12 or by selecting Tools > Developer Tools in IE8.

Second always remember that to inspect a script you need to select it first and start debugging.  In IE Developer Tools > Script tab > Select script > Start Debugging

Selecting Debugging Source

Inspecting Javascript Variables

The most convenient use of firebug for me is of seeing the JS variable values as I develop a complex client-side application. As I discussed above, you don’t want to see alert boxes again and again, IE developer tools, do that for you in two ways.

You can use console to see any output messages. To differentiate between these messages, different console.log APIs are available:

  • console.log
  • console.error
  • console.warn
  • console.assert

My favorite in firebug was console.debug but I left using that long ago because IE Developer Tools do not support console.debug and this will break your code. Secondly firebug allows you to format those error message, IE  Developer Tools do not support that (or at-least something I am not aware of). The output of these console messages will be exactly like something you see in firebug. For the record, you write code like this:

var myvar = 0;

IE Developer Tools Log Messages

The other way is slightly different, can be used for the same purpose but is related to only variables, you are able to see variable values at your breakpoints, so you have the time to analyze them.

To create a break point, hover your mouse on the line number you want to mark as break point and click, a red dot will appear on the left beside the line number, now when you will start debugging, browser will stop executing it just before the line you marked as break point.

Then go to the right hand pane of IE developer tools and select Watch > Click to add the variables you want to see and developer tools will let you know the variable name, value and type at the break point.

Watch variables at break point

You are able to change variable values at this moment as well, just when you are watching a variable in Watch tab, open Console tab and assign new value to the variable to see how it will behave after you hit Play again. In the same manner you are able run any instructions which are not in source code but you want to run them at break point to analyze the effect.

Part 1: Running script at break point

Part 2: IE Developer Tools console with new variable value

Now go back to the Watch tab and see the updated value.

Part 3: Watch updated variable value

Profiling Javascript

Another important need for a web developer who do not think that JS is just a scripting language and it just has bits like getting an element and changing it’s value at run time etc. but it is so important that the developer actually needs to optimize the run times and to see how many times a function is getting called, JS profiler is just what saved our lives in firebug, it is here too in IE Developer Tools.

You need to select Profiler tab in Developer Tools > Start Profiling, do something on your page like refresh or wait for sometime if that is something you want to check and then Stop Profiling, Developer Tools will give you a complete report of JS activity done in that time span, listing Functions, count of the calls made and inclusive, exclusive time etc. Same information can be seen in Call Tree view if you select call tree from Current View.

Javascript Profiler

View Generated Source

If you ever worked with Ajax, you would probably know the importance of seeing the DOM once your Ajax call has been made and your DOM has got updated. In Firefox I use Web Developer Toolbar to see Generated Source, in IE Developer Tools, you can view the same by going into View > Source > DOM, you can view the Original source code and the selected element’s DOM as well.

View Generated Source

Outlining Elements on the Page

Another important tool of firebug is when you can outline the elements on your page to see where they are residing, like the divs or tables etc. I specifically use Web Developer Toolbar instead to outline and see the cause of cosmetic issues. IE Developer Tools comes with this solution as well. You can go to Outline in menu and select the type of elements you want to outline or to select an individual element you can go to Any Element and add the name of the element to view outline.

Outlining Elements

There are plenty of other functions which Developer Tools support like you can also see the CSS of an individual element by going to Find > Select Element by Click and then clicking on the element, just like you do for inspect element tool in firebug. You can view Images information or disable scripts, CSS, change the browser modes to render the page in IE7, validate your HTML (this will take you straight to W3C website and if you are working on localhost on your system, chances are W3C will refuse to check your code), CSS etc and you can even re size your browser to see your pages in different resolutions.

There is no doubt, Microsoft was under pressure from the developer community to bundle the developer tools with IE because after the arrival of Firefox, the whole development scenario got changed and developers want to develop more rich applications for the web. I personally havn’t adopted IE for my core development but it is handy to check my code every now and then in IE to see if everything is fine there and if not, using Developer Tools makes the life easier by allowing you to debug the code.

Feel free to comment if you have anything to say!

About me

Just another Londoner writing about life in the city, politics in general, technology and other gossips. Keep following as this will not be like any other blog.

If you want to get in touch personally, feel free to ping me on linkedin:

YUI Dialog: Hiding the Dialog Panel in IE – Bug Resolved

This fourth installment in YUI series is basically about firing a bug which appears to be IE (Internet Explorer) only. This is when you have opened an iframe in dialog widget and showing another resource using frame.src and relying on native

close : true

parameter of YUI Dialog widget to show a close button to the user on top of the dialog and when user clicks it, your dialog panel get hidden. Works very well in Firefox and Chrome but when I went to test in my IE8 installation, it went wrong.

The Error

The error was this, when I was closing the dialog panel in IE, it was getting hidden but leaving some traces of it back, in most of the cases, border of a table which was in the iframe, meaning dialog was not getting properly hidden. It was also not allowing me to click or change any thing in the background elements  in the parent page, reason because IE was still thinking that dialog is on top of those elements.

The Code

The code I was using to pop up a new dialog panel to show a new regular page to the user in dialog iframe:

<script type="text/javascript">        
 // Instantiate the Dialog
 var addCons = new YAHOO.widget.Dialog("addCons",
 {   width : "965px",
 y: 15,
 x: 500,
 modal: false,
 visible : false,
 constraintoviewport : true,
 draggable : true,
 monitorresize : true,
 close : true});
 var DialogShow = function(e, args, o){
 var frame = document.createElement('iframe');
 frame.src = "";
 frame.width = "100%";
 frame.height = "580";
 //subscribing to the on show event
 addCons.showEvent.subscribe(DialogShow, addCons);
 YAHOO.util.Event.addListener("showHL", "click", function(o) {;});

I tried couple of work arounds but this idea really works well that ofcourse the dialog panel’s body is having problems, then just set the body to null on hide event.  So I subscribed the hide function with the hideEvent of dialog:

var DialogHide = function(e, args, o){
 o.setBody(' '); //set the body to null to avoid IE problem
 //subscribe the hide event
 addCons.hideEvent.subscribe(DialogHide, addCons);

Another requirement was to enable the user to press ‘Esc’ key to hide the dialog panel. We need a Key listener event then from yui utils to listen on key 27 (which is Esc key). Add the following bit of code just before we render the dialog widget:

var keylistener = new YAHOO.util.KeyListener(document, { keys:27 },          
 { fn:addCons.hide,
 }, "keyup" );
 addCons.cfg.queueProperty("keylisteners", keylistener);

View the example source code to have a look at the full source code.

View YUI Dialog Example in New Window

YUI Calendar: Using and modifying multiple calendar picker instances on single page

In this third installment of how to create and modify existing widgets from YUI Javascript library, I will explain how to create multiple instances of calendar widget of YUI2. There are many examples of how to use Calendar widget on YUI’s official website but for my application, the requirement was to to schedule multiple actions on the same page, giving each one a date of its own, so I developed my calendar widget with the example found here.  As a matter of fact if you really want to include multiple elements of a same type on a HTML page, you assign them different ids so that they can be accessed and called appropriately (just like you do with your babies).

You can see in the example I have built on, we are using here the power of Dialog container of YUI, we are using its button and context features to support our pop-up calendar.

It’s best that you first see my example code working and then I will explain the code.

View Multiple YUI Calendar Example in New Window

If you see the source code of example, you will see what I have really done is that, I have passed a unique ID for each calendar instance through declaring

<script type="text/javascript">

Then I enclosed all of the code in a function, which accepts the calendar ID and each variable which declares the calendar, gets embedded with this calendarID so that whenever a user uses any instance of the calendar, my widget knows about which calendar we are talking about and the calendar instance needs to update which fields. The same id is needed to be embedded in HTML fields which we are updating through (of-course using powerful features of DOM manipulation given by YUI)

Dom.get("month-field"+calendarID).value = month;
Dom.get("day-field"+calendarID).value = day;
Dom.get("year-field"+calendarID).value = year;

and at the end we really need to ensure that our HTML bits have those IDs

<span id="datefields1">
 <label for="year-field">Year:</label>
 <input id="year-field1" type="text" name="year" value="" style="width: 3em;">
 <label for="month-field">Month:</label>
 <input id="month-field1" type="text" name="month" value=""style="width: 2em;">
 <label for="day-field">Day:</label>
 <input id="day-field1" type="text" name="day" value=""style="width: 2em;">

Note the input id parameter, which is year-field1, month-field1 and day-field1, you can create as many calendars as you want, if you have specified the input ids and declared calendars with those ids.

There is one other bit which I have manipulated is the default behaviour of calendar when it updates a field, I was required to have date stamps in the format of YYYY:MM:DD while the calendar would update the fields in the format of YYYY-M-D format, for this functionality there may be some call given by YUI Calendar widget itself because I have seen several type of formats floating around in examples section but for me it was really quick to modify my function to include preceding zeros (if there are none) to month and day before I populate the the DOM elements:

//This modification is done to cater calendar out from yui to
//give always the leading zeros for months and days, in case they
//dont have
 var month = ''+aDate[1]+''; //convert month into a string
 var day = ''+aDate[2]+'';    //converty day into a string
 var year = ''+aDate[0]+'';    //converty year into a string 

//embed the preceding 0 if month is of 1 digit
 if (1 === month.length) {month = '0' + month;} 

//emebed the preceding 0 if day is of 1 digit
if (1 === day.length) {day = '0' + day;}

Other than these you will see how this function is subscribing certain events. One important event is to hide the pop-up calendar when a user presses ‘Esc’ key

// Pressing the Esc key will hide the Calendar Menu and send focus back to
 // its parent Button
 Event.on(window["oCalendarMenu"+calendarID].element, "keydown", function (p_oEvent) {
 if (Event.getCharCode(p_oEvent) === 27) {
 }, null, this);

For the calendar I am using default button provided by YUI CSS, you can change it by declaring your own calendarpicker button style in CSS like:

#calendarpicker button {
 background: url(../../images/calendar_icon.gif) center center no-repeat;
 text-align: left;
 text-indent: -10em;
 overflow: hidden;
 *margin-left: 10em; /* For IE */
 *padding: 0 2em;    /* For IE */
 white-space: nowrap;

change the background URL to your own image.

Feel free to comment if you have any better ideas to make this example more robust.

YUI Panel: Changing buttons and re-using a panel on same page

YUI is a natural Javascript library, it is different from jQuery and other Javascript frameworks due to its closeness to original JS where it supports you to build widgets and enhance the user experience, the other JS libraries such as jQuery and Dojo are incredibly easy to work in but they divert you so much from the original language that they become almost a language of their own. The closeness of YUI to the Javascript at the one end gives you the depth to work at your own ease and develop whatever you want, on the other hand it proves to be a bit difficult for the beginners, probably that is the reason, you will not find much support for YUI around, YUI has its own forums where the original developers of YUI reply in time-efficient manner as well but they speak at very high level and people to support at beginner and middle level are very less on Google.

So, I have decided to write some blog posts about the problems I faced and I was not able to find help on Google but then I figured out in some way (occasionally from the help of developers at where I got some hints and I made something out of it). I have already wrote first in this series which was about IE rendering problem in YUI tabs, today I will explain how you change modal panel buttons on the fly.

The requirement was to make a modal panel in YUI, which work at its own as a activation widget using Ajax (YUI connection manager). The idea was pop up a YUI panel when a user clicks on “Activate”, that modal panel will allow the user to enter details of when he/she wants to schedule the activation (where user can choose now or a later date) and then user can hit Submit and Cancel buttons. Uptil now its usual YUI panel which you will find in any YUI panel example, here is the example of making this panel:

//function to execute if user clicks on Cancel button
var handleCancel = function() {

// Instantiate the Dialog
 var dialog23 = new YAHOO.widget.Dialog("dialog23",
 { width : "340px",
 fixedcenter : true,
 visible : false,
 modal: true,
 constraintoviewport : true,
 hideaftersubmit: false,
 buttons : [ { text:"Submit", handler:handleSubmit, isDefault:true },
 { text:"Cancel", handler:handleCancel } ]
//delcare the call back
dialog23.callback = { success: handleSuccess,
 failure: handleFailure };
 // Render the Dialog

//attach the listener to Activate (button, div,
//span where ever you want to attach the click listener)
YAHOO.util.Event.addListener("Activate", "click",, dialog23, true);

A function of handleSuccess is missing in this example, I will leave that to you because in my code its very inter-related. The handleSuccess is where I make an Ajax request through YUI connection manager, once the request get submitted, I show a spinning wheel and then the Ajax response get shown to the user. The problem here is, you can easily show the response but changing the buttons at the bottom became a night-mare. Once the response is shown, you don’t really want to show the user Submit, Cancel buttons, what you really need there is a OK button so that user can acknowledge and on acknowledgment the panel hides away.

Here is how you change the button at the bottom of YUI panel:

//embed the OK button, on click handleOK function will be called
 dialog23.cfg.setProperty("buttons", [ { text:"OK",
handler:handleOK, isDefault:true }]);

and then write a funciton to act when user press Ok

//these are events which happen after a user clicks OK
 var handleOK = function() {
 //hiding the dialog box

There is one other approach I am using in this panel, that is if once activated, the user clicks on the Activate/Deactivate button again, what will happen then? You really need to make it dynamic.

For example your panel HTML was this:

<div id="dialog23">
<div align="left"><div id="ajaxResponse">
<form method="POST" action="timeschedule.php">
 <input type="hidden" name="buttontime" value="1">
 <div id="resp"></div>
<div>Enter the date here: <input type=text value=date name=date>

In this case before initializing anything get the all the ajaxResponse innerHTML in a variable like:

var div = document.getElementById('ajaxResponse');
//we are storing schedule HTML which we will restore at the end
var divHTML = div.innerHTML;

Now our ajax response will change the bits you get in ajaxResponse div, the input text box and other will be changed something like:

User specified action has been activated.

What you need now is to restore the original panel just when the user clicks OK, the handleOK function will get changed to this:

//these are events which happen after a user clicks OK
 var handleOK = function() {
 //restore the schedule HTML in case user wants to use it again
 div.innerHTML = divHTML; //populating the initial schedule HTML back
 //hiding the dialog box
 //rebuilding the submit and cancel buttons for re-use
 dialog23.cfg.setProperty("buttons", [ { text:"Submit",
handler:handleSubmit, isDefault:true },
 { text:"Cancel", handler:handleCancel } ] );

And here you will replace the buttons in the bottom of the panel again to Submit and Cancel.

I have elaborated enough here to give you an idea of how things work, its possible you are not working on same thing but my idea was really to give you ability to change buttons in the panel on the fly and to give you an idea that how you can use a panel again and again. If you need any further help, don’t hesitate to comment and I will try to reply as much as I can.

YUI Tabview and IE: Rendering Problem Solved

YUI Tabview is the easiest way I came around to organise your web pages into tabs, rather than using multiple selective navigation. YUI Tabview can easily be used to organise a very long page into chunks or you can give it an external source which it collects through Ajax and show to the user. Different parameters are available while making these calls such as cacheData and active, which allows you to cache the contents after fetching through ajax while active parameter let you decide that should tab fetch the data on page load or should it wait until user clicks on the tab explicitly.

There is a problem of inline script exeuction in YUI2 version (I haven’t tested YUI3 yet). Bubbling library gives an alternative to it. Bubbling Library is a YUI extension and by simply including dispatcher plugin of bubbling, you will be able to run inline javascripts in the tabs content. From inline I mean, the YUI Tabview by itself is a javascript, when it calls a source which also have <script type=”text/javascript”> tag in it, it breaks away and just do not show you anything. Dispatcher on the other hand makes separate nodes of each script tag and hence let you execute any javascript in your tabs.

Example to call tabs content through ajax using dispatcher plugin for YUI:

<div id="container">
<script type="text/javascript">
  	var tabView = new YAHOO.widget.TabView('contenttabview');
        YAHOO.plugin.Dispatcher.delegate( new YAHOO.widget.Tab({
        label: 'Leave a comment',
        dataSrc: 'yourexamplefolder/yourexamplepage.php',
        cacheData: true,
        active: true 

When I started using YUI Tabview, the first hurdle was to execute inline javascript which I was using for form validation etc, dispatcher solved, but just when I was about to finish the module development and went on IE (I was developing on Firefox) to check, it just didn’t went well, for those pages which had tabs with lots of content in it, IE just seemed to break its while fetching data through Ajax. It wouldn’t get the whole script running and would die out somewhere in middle. Luckily I had a universal footer and I got it straight away that footer is not executing that means browser is just not getting there.

The Solution:

After getting the problem, solution was simple, just call your tabs script only when the whole of your browser’s DOM is ready and loaded. There is a very handy functions of YUI2 Event Utility:

//which works like

 function init() {
    YAHOO.util.Dom.setStyle("hidden_element", "visibility", "");

But I will stick with native javascript function of


Here is how you modify the above example to work with IE to solve any potential rendering problems:

<div id="container">
<script type="text/javascript">
function tabs(){  	
       var tabView = new YAHOO.widget.TabView('contenttabview');
        YAHOO.plugin.Dispatcher.delegate( new YAHOO.widget.Tab({
        label: 'Leave a comment',
        dataSrc: 'yourexamplefolder/yourexamplepage.php',
        cacheData: true,
        active: true 
window.onload = tabs;

Happy Coding 🙂

Time Efficiency – Controlling Java applet from Javascript especially if you make round-trips to the web page from applet

My application architecture is like this,  for the easiness I will say that there is a clock on my page which a java applet updates every second, that clock shows the server time (in actual my java applet is updating other data as well). This java applet runs continuously once the page get loaded, I am loading it at the end of the page and it is a faceless applet.

Then I have this form for example:

<form id="liveClock">
  <input type="hidden" id="DivID" value="Nothing Yet">
  <input type="hidden" id="DivVal" value="Nothing Yet">

Now my java applet on the page, places the DivID which needs to be updated in DivID element and value of it in DivVal element.

Say after java applet places the DivID and DivVal, these elements look like this:

<form id="liveClock">
  <input type="hidden" id="DivID" value="Clock">
  <input type="hidden" id="DivVal" value="11:02:59">

A javascript function then picks up the data from the DivID and DivVal and updates the Clock div on the HTML page.

<script type="text/javascript">
function updateClock(){
//get the input element data placed by java applet
var DivID = document.getElementById("DivID");
var DivVal = document.getElementById("DivVal");
//now get the clock div
var clock = document.getElementById(DivID);
//check if we really have got the clock div element
if(clock != null){

After placing the data in input elements, java applet calls the updateClock function of javascript, which executes and update the clock on the page. Why applet is not directly updating the div element because applet is also used to update several other elements on the page and each update is coming at once in the form of a comma separated string, explaining all that is beyond the scope of what we are trying to achieve here.

Ok, applet is now running every second, placing data, then calling javascript and javascript is then updating the fields on the html page.  Java on its website says that if you are updating javascript on the web page from Java applet, avoid making round trips, the primary reason is that java applets are multi-threaded while javascript in a browser is single threaded and my applet is indeed a multi-threaded applet, however, I am using one thread explicitly to update the contents on the page while the other one to fetch the update from the back-end.

The problem I was facing that from time to time, whenever my applet is sitting there, sleeping for sometime and then updating the content, if user navigates away from the page, it produces some errors like DivID was not found or updateClock was not defined, while both are there in HTML page.

Root Cause of the Problem

Root cause of the problem was my browser was slow to unload and tear down the java applet while moving to another page but my applet was faster in execution and supposedly its 500ms wait finished while the browser has unloaded the DOM containing DivID element but applet would still try to go and update the element, that will throw errors in the browser.

The Solution:

The solution is simple:

in your HTML page header:

function closeIt()
  document.liveClock.APPLETID.PageLoad = 0;
window.onbeforeunload = closeIt;

where APPLETID is the ID of your applet element on the page. Then in your java applet declare a public integer PageLoadand initialize it with one

public int PageLoad = 1;

Now just when you write to the javascript through doc.eval(string), check the PageLoad variable

if(PageLoad == 1){

So, we are turning off our applet’s writing abilities just when browser is about to unload the page. The onbeforeunload event of javascript is not very famous but becomes very handy in this case.

Hence, we have worked around a problem to which both browser and java wasn’t addressing.

Happy Coding 🙂

Get Adobe Flash player