Debugging iPad / iPhone web based apps using Firebug lite bookmarklet

While the XPages Extension Library contains a control to use the firebug lite control, you might want to use it to debug a production app and or an Angular application which is not residing within XPages. You can do this on Firefox by installing the plugin, but it gets harder when you are testing cross multiple browsers and especially on an iPad where the development tools are limited.

You can install firebug lite as a bookmarklet within your iPad bookmarks by following the instructions on this site:

Using the link you can then debug (with some difficulty but way better than nothing) your applications by looking at the in and out-going traffic from the page.



Editing and testing your XPages CSJS “in real time” using Chrome Developer Tools

In this article I will demonstrate how you can make live changes to your CSJS using firebug and chrome deveveloper tools and figure out where your bugs are happening before committing them to your XPages database.


First rule of thumb – put as much of your XPages Client Side JavaScript (CSJS) in a JavaScript script library as possible. The reasons are compelling and simple:

  • Separation of code makes for much easier maintenance
  • Changing CSJS libraries required a CTRL-F5 to view the changes and no BUILDING of the database code

The demonstration

I have created a very simple XPage and my code is not working – I want to find out why not. I could use the console to test my code and just run it before updating the CSJS library – but I wanted to show this method of debugging because it is probably more applicable to a more complex function than this simple one. The XPage source looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="">
		<xp:script src="/csjsFirebugChromeDemo.js" clientSide="true"></xp:script>

	<xp:button value="Click me" id="button1">
		<xp:eventHandler event="onclick" submit="false">
	<div class="change"></div>

As you can see I have a button, a div and an included CSJSFireBugChrome resource This is the library

function changeMe(){
	$('change').html('this changed')

When I load the XPage and click the button nothing happens – why not? Well it is because the jQuery selector is wrong.

$(‘change’) will select all the elements with a Tagname CHANGE rather than selecting the class change which is really what I was looking to do. Let’s see how we can play with this in two dev environments.

Firebug console

As I have mentioned in other articles – a JavaScript function is easy to over-ride in the console. The global namespace for web browser Javascript is “window” and all functions live there by default. To over ride them we just use window.functionname in the console and create our own function. This demonstration is also applicable to Chrome Dev Tools console.

The example below shows what happens when I over-ride the function through the console. Not that I have added the .changeMe in the jQuery selector.


Then when I run the script and click the button again – success


Chrome live editing

Opening Chrome Developer tools allows you to view the “Source” of the files used in your XPage and edit them. This technique only works on the scripts which are loaded through a library – you cannot edit the code if it is inline within your HTML code. When we look in the chrome source we can see the CSJS function already there – hit F12 to make it come up and select the source option. Click on the arrow top left


Which then gives us the function


This is editable !! All you need to do is make the change and then do a CTRL-S the save the change. (This is of course only changing the cached version of the function in the browser and not saving it back in your XPage). When we click the button again it now works 🙂


Advanced changes using breakpoints

This is where it can get really cool 🙂 As I mentioned before you cannot make changes to code which has already executed and code which in inline – but what you can do is set a breakpoint in the code and edit it before it is executed…..

In my EXTJS locking grid article I demonstrated that you can lock a certain column. Once the EXTJS code is run I cannot edit it through the Chrome source but I can make changes the code pre-execution using a break point. This way I do not have to keep saving  the XPage I can just reload the page and make changes as I see fit until I am happy with the code. This is the code and you can see the locked column is the lastname one.

    var grid = Ext.create('Ext.grid.Panel', {
        renderTo: 'gridHere',
        frame: true,
        features: [filters],
        height: 400,
        title: 'Users',
        store: store,
        iconCls: 'icon-user',
        columns: [{
            header: 'First123',
            sortable: true,
            dataIndex: 'firstname',
            filterable: true
        }, {
            text: 'Last',
            sortable: true,
            dataIndex: 'lastname',
            locked: true,                //here is the locked on lastname
            field: {
                xtype: 'textfield'
            filterable: true
        }, {
            text: 'Address',
            sortable: true,
            dataIndex: 'address',
            field: {

I add a breakpoint in the code by clicking on the line number in the source code


I then reload the page and the breakpoint stops where I told it to in the code execution


I then change the code to lock the First123 column and not the lastname column by editing the JavaScript in the source


et voila 🙂


In this article we have seen how using the Chrome Developer tools we can effect change to our CSJS without having to resort to re-saving anything in out XPage application. I especially like the breakpoint editing which *really* helps me to pinpoint my code errors and make sure they work before I change my XPage.

This is extremely productive

Dojo Firebug Extension – from an XPage developer’s perspective

In this article I take a rather irreverent look at, and describe some what I was hoping would be, the useful capabilities of the dojo firebug extension available at


I love firebug for my client side JavaScript development – for many reasons too numerous to mention here. If you have no idea what firebug is then you should google it and find out – USE IT and you will never go back…..

So what’s this Dojo extension all about then ?

Right off the bat I loved finding this quote “The Dojo Firebug Extension started as an internal IBM initiative to help IBMers working with Dojo.”, and more importantly got me straight off on the thought of what can this do for me in my XPages?

The documentation is available here – and as firebug extensions go – this one is fairly well documented – nice job 🙂

You have to download a different version based on your firebug and your firefox version….that’s kinda weird and disconcerting and they don’t have my version of firebug or firefox – but hey we truck on in hope.

So What does it do for me as an XPages developer?

Good question – let’s find out…

Well the first thing it showed me was how MASSIVELY complicated the Dojo integration with XPages is……check out some of these idTags on this Tab Container!! 😮

Dojo Firebug extension in action
Dojo Firebug extension in action


Open API documentation

This *could be* really useful – if you can get over how useless the API documentation site is – let me paraphrase…….IF you understand how the Dojo API documentation works this *could be* fantastically helpful…..

In my previous article on how I figured out how to use the Dojo Tab Container doLayout (where the screenshots come from) I was struggling to find out what I needed to make the Tab Panel heights dynamic. Would this have helped?….I was kinda bitter at this point as I figured it would have….so i soldiered on..

Select the tab container and look at the extension

Selecting open API documentation
Selecting open API documentation


and opening the API documentation

Dojo API documentation
Dojo API documentation


*yawns* – so not really – but stay with me

The next options *looks* more useful (so why did you show us the API link? Yes you guessed it…… it *is* ‘cos I hate you and I wanted to force you to look at Dojo API documentation – get over it and don’t ask daft questions)

Open Reference Guide Doc

Open Reference Guide Doc
Open Reference Guide Doc


Which shows you this…….

Dojo Reference Guide Documentation
Dojo Reference Guide Documentation


First of all I am really impressed that this actually links to the 1.8 version which was only released this week – but that is also not helpful because XPages 8.5.(What I am using) uses 1.6 so which a quite switch over on the right hand side

Switching to 1.6
Switching to 1.6

We get…

Aw Butts - really?/?
Aw Butts – really?/?

And I was just saying how awesome you guys were – CRAP.

As it turns out the plugin is too smart and not smart enough to detect 1) the version of dojo I am using and 2) that this feature it thinks I am using is available in 1.6…


DOH *grrr*


So I didn’t solve that problem but I did find another one – I noticed that IBM modified the Dojo specifically for the extlib!! …if you look at the code reference in the extension

Well that is kinda interesting I guess..
Well that is kinda interesting I guess..

[view:_id1:_id2:_id39:djTabContainer1 (Widget extlib.dijit.TabContainer)]

and when we select to go to the Reference Guide Docs – the URL it is sent to

You will see that extlib has been inserted into the URL

the REAL documentation is here

dijit/layout and not extlib/digit.

If you look at an example from david walsh’s blog you can see the difference…

vive la difference
vive la difference


Anything else?

Well I found out how to manage FireFox profiles – which is kinda useful – so I did learn something useful from this investigation.

There are a number of cool Dojo debugging capabilities if you are really into writing seriously with the dijits whereby you can subscribe to the data and watch it move all over the place – kinda cool – not helpful for XPage development though.

So is this really useful for an XPages developer?

Well I have to say from an purely educational perspective it is really interesting to get an insight into how the dijits work…

Some really complex cool stuff going on  in here
Some really complex cool stuff going on in here


But I think my overall impression of the extension is that it will not help an XPage developer develop their XPages at all in any sort of way

Shame really 😦


Let me rephrase that last sentiment – I think this COULD be really useful if IBM were inclined to apply some time and effort to making a similar extension for XPages Dojo development – but isn’t the point of XPages is kinda so we don’t have to worry about Dojo…so it would be an uber-dojo-geek expert XPages developer tool only…meh…who wants to do that?? 😉

Shame really 😦


That is two blog articles in a row about dojo – don’t worry I am not going back to the dark side – jQuery still rocks my world 😉

jQuery in Xpages – development tip – using Firebug Console

In this article I will demonstrate how using Firebug can significantly reduce your development time with jQuery (or dojo) when you are trying to use selectors. There is no doubt that that out of the box functionality provided by XPages is very powerful, but to accomplish the capabilities we all know (and love?) the accompanying HTML is complex and not necessarily easy to navigate manually.

For more information on FireBug check this out

Things are busy at home and at work so I won’t have a plugin demonstration this week – just a development tip

As I have discussed in this blog, using dojo and JQuery selectors are a very powerful way to facilitate “enhancing” your user experience with some nice UI changes. Many times however this can be a frustratingly slow process if you are doing trial and error development something like this:

  • Write your jQuery selector code in the XPage source panel
    • Save
    • Test In Webpage
      • Nothing happens
  • Change your jQuery code is XPage source panel
    • Save
    • Test in Webpage
      • Nothing happens
    • Curse
  • Change your jQuery code in XPage source Panel
  • Remember what it was like in the good old pre-XPages days
  • *sigh blissfully*
  • Curse
  • continue…..

Using the FireBug console we can significantly speed up this process by enacting real time changes to the webpage and not creating the XPage code until we know we have good working JavaScript.


Here is a sample page with a typeAhead and a ViewPanel

typeAhead and ViewPanel
typeAhead and ViewPanel

and here’s our firebug console with a simple piece of jQuery code to change the css of all input fields, giving them a red border

  • Enter the text
  • Hit run
  • And there we have it – nothing happened ?!?
  • Curse
  • #FAIL 😦

What happened?

Well if you look over on the left you can see the jQuery object which has been returned

jQuery object returned
jQuery object returned

Clicking on it shows us the element and look it DID get set……..

Viewing the field through firebug
Viewing the field through firebug

What’s happening is that the INPUT we see is actually masked by DIV styles which are pegged as “!important” in the stylesheet and over-ride the inline style 😦 Can you imagine how long it would have taken you to figure that out just by looking at the code? Using FireBug has given us a quick insight into what’s going on….so if we want a red field then we have to traverse up the Document Model (DOM) tree and color the DIV containing the INPUT field…..

As you can see below I tried a few examples but could not get the field to color – and then I took too many parents and made all the DIVs red. it is also a fascinating way to see in real time how the jQuery DOM navigation works…..still I don’t have what I was looking for – a red field on its own 😦

Too many Red DIVS
Too many Red DIVS

Starting again if you look at the HTML in the DOM you can see what needs to be selected and we can make it red….select the DIV with the id ending in inputText1

  • yay !
A Red field!
A Red field!

Now of course you wouldn’t do this in real life – you would set a class and/or style on the field in the XPage client but this is a demonstration 😉

Coloring the viewPanel

We can use a CSS3 selector to style the nth column of the viewPanel – but unfortunately this does not work in IE

		TABLE[id$='viewPanel1'] td:nth-child(3) {background-color: yellow}
CSS fail in IE
CSS fail in IE

But jQuery rocks browser incompatibility issues and we can use firebug to get the right  jQuery and then apply it through the code to work in IE. Yes we used firebug to make sure the jQuery works – but this is jQuery and it is BUILT to overcome browser incompatibility issues. Instead of using the CSS3 nth-child selector, jQuery detects IE and trverses the table manually looking for the nth child in a loop – this is inefficient but the final effect is the same.

This is a big reason why you should use a library like jQuery or dojo – they were designed to help get around browser incompatibility problems.

jQuery CSS selector
jQuery in the firebug console
		$("TABLE[id$='viewPanel1'] td:nth-child(3)").css('background-color', 'green')
jQuery rocks around IE CSS support failure



I hope you enjoyed this quick(ish) tip. This only scratches the surface on FireBug and there is SO much more to learn/discuss !