Software creative always looking for a challenge

Quick Tip: Customizing your chrome dev tools

Screen Shot 2016-06-16 at 6.04.26 PM

I recorded  a quick screencast to show how to customize your chrome dev tools to have a different color theme. So take a look and show your colors!

The stylesheet shown is available on:


Mac OSX: ~/Library/Application Support/Google/Chrome/Default/User StyleSheets/Custom.css
Windows: C:/Users//AppDataLocal/Google/ChromeUser DataDefaultUser StyleSheetsCustom.css
Ubuntu: ~/.config/chromium/Default/User StyleSheets/Custom.css

Based on a post by Darcy Clarke.

Reborn: Simplicity and Focus

The Big Bang

As you may have noticed the site has a fresh new look now. But it is more than that, much more. I now have a more focused approach to the content and a simpler website to navigate through.

Many of my personal heroes — including the super heroes listed on the bottom — have an incredible sense of focus, which contributes in no small part to their success. I have been hearing about the need to focus a lot lately. More…

Getting Reliable z-index Cross-Browser

Javascript Code

It is not as easy as you might think to get the correct z-index of an element using a javascript call like $(element).css(‘z-index’). The problem is how browser vendors apply the z-index to an element. But, no worries I have created a jsfiddle page to demonstrate the problem and more details on how it works will follow. More…

Multiple Popup Windows Workaround


In Firefox, if is called before a previous call to this method had a chance to return, multiple windows would appear, even if the same window name is used in all calls. You might ask yourself, when does this really happen? Well, just think of an event handler being fired multiple times. Let this event be an onclick event and lets use the following event handler for it:

{code class=”brush:jscript”}

Click on the example link in Firefox as fast as you can example.
You should see multiple popups opening if you clicked fast enough.


But wait, Mozilla recommends a different way to open a new window. Consider the following code:

But this does not work either. The windowObjectReference remains null even after the initial call to This is due to the fact that the function does not return immediately like the documentation suggests (the function is described as Asynchronous). More about that in the next section.

The bug you have just witnessed is described by Mozilla here. This bug has been open for 5 years now and is not yet fixed in Firefox 4.0 beta (although the speed ups to the JavaScript engine help mask the problem).

In IE 7 multiple windows will open, but once the page has been loaded into the popup window, other windows with the same name will be closed. IE 8 seems to have gotten rid of this problem completely. All other browsers seem to act as expected, so this is almost purely a Firefox issue.


Although I can only speculate about the true cause of this problem without diving into the code, after a few test I believe I narrowed down the root cause of this problem. The problem seems to be caused by the way that Firefox decided to handle event dispatching in JavaScript. Like in dispatchers in other browsers, the events are entered into a priority queue by time. However, unlike in Opera for example where an event handler is executed to its’ very end, here it can be interrupted mid-way through when waiting for I/O. Modern operating systems usually block threads/processes waiting for I/O and let other processes run in the meantime. When I/O is ready to be consumed, the thread/process wakes up. This seems to fit our symptoms perfectly. Opening a new window usually results in a new thread or a new process, and since a request to open a URL in a new window is an I/O request, the thread is blocked. Now a new event can be serviced and it’s handler can be invoked, but in our case it is the same event and the same handler. This is exactly what causes the problem, the order events in the queue are serviced generates some unexpected results.

To convince ourselves lets create a little experiment:

{code class=”brush:jscript”}



<title>Popup Window Experiment</title>

<script language=”javascript”>


// Call count will count the number of interrupted calls, if there are no interruptions

// then it will always be 1 when the function body is executed otherwise it will be more than 1

// meaning that the previous call to the handler did not get to complete it job and decrement the

// variable back to its original value before the call.

var callsCount = 0;

var callsCount2 = 0;

var myWinObj = null;


// this handler will be blocked when waiting for I/O, we will see this by observing

// pop-up windows with numbers 1, 2, 3, 4… matching the number of clicks while waiting for I/O

function blockedHandler() {


myWinObj =“”, “myWin”, “width=100,height=100″);





function pause(millis) {

var date = new Date();

var curDate = null;


do {

curDate = new Date();

} while(curDate-date < millis)



// this handler will not be blocked, demonstrating that when there is no I/O event handlers

// are not blocked (also known as non-preemptive behaviour)

function nonBlockedHandler() {



document.body.innerHTML += ‘<br />’ + callsCount2;








Click on the following link multiple times really fast, to see that you will get different numbers in each new popup window in

Firefox:<br /><a href=”javascript:blockedHandler();”>Blocked on I/O Popup Demo</a>



Note: how the lowest number (1) is on top, indicating the first call finishes last.



Click here to see that non-I/O events do not get interrupted during the execuation of their event handler:<br />

<a href=”javascript:nonBlockedHandler();”>Not-Blocked on non-I/O</a>





This experimental code is very important to understand since we will use it as the basis for our work around. You can try it on this page here.

The blockedHandler  function demonstrates how an I/O event — loading the url into the new window — is interrupted in the middle, evident by the different numbers printed in the new windows. If the event handler was not interrupted then the count would drop back to the original value when it reaches the callsCount– line. Instead, it enters another event handler and increments the value again. So the printed value will be different than the original. It is also important to note how the first call completes its work last (again we can tell by looking at the numbers).

The nonBlockedHandler function demonstrates how a non-I/O event, or a CPU intensive event, does not get blocked and runs until completion. In contrast to the previous test that gave different numbers in each window, this test produces the same number in the main application window. Since there is no I/O, nothing gets blocked, only a very intensive loop. This shows JavaScript is single threaded, the event handlers themselves do not get preempted. However, as the browser creates new threads for a new window in the blockedHandler these threads do get preempted by the OS when they ask for I/O.

To conclude our findings, JavaScript is indeed single thread, but the browser is using multi-threading which causes our symptoms. So how do we cure concurrency problems just by using our single threaded JavaScript?


Initial Design

Not giving up on Firefox, I came up with a simple work around that looks like this:

{code class=”brush:jscript”}

var linkOnClickCalled = 0;

var linkOnClick = function()  {


if(linkOnClickCalled <= 1)  {‘newWin’, ‘width=400,height=400’);





The idea was simple, use the results of our previous experiment to skip all the calls until our event handler returns. But this looks a little ugly and is not very scalable, therefore I cam up with the next design.

Refined Design

Notice the similarity of the initial design to how Semaphores work. A good place to look for inspiration is then of course the Linux c library semaphore.h, which we will use to improve this work around:

The first change I had to make was to invert the count to start at n and go to 0, just like a true semaphore. Next, I used the idea of closures to get rid of the global variable we used for counting. This piece was inspired by Douglas Crockford’s, JavaScriptThe Good Parts, page 44 which describes a very similar technique to make caching reusable. It works due to JavaScript inner function staying alive even as outer functions return, allowing access to the outer function’s variables.

Note that unlike true semaphores that block a thread if the count is smaller or equal to zero (<= 0), our code just skips that section. This is why I called it a skip semaphore here. Also, there is no queue to keep waiting events (since we skipped them). Finally, there is no signal and wait. So in the true spirit of JavaScript we have something not seen anywhere else, but still bares some resembles to other things.


Mozilla Bug Report –

Opera Developer’s Channel, Timing and Synchronization in JavaScript –

Concurrency in JavaScript –

Mutex in JavaScript –

Separate Processes For Tabs, Mozilla Wiki –

Douglas Crockford, JavaScript: The Good Parts, 2008 Yahoo Press

Snow in JavaScript


Winter is finally over, but we can still make nice digital snow to cool us down during hot summer days. We will start by considering the path snow flakes take before they hit the ground, then we will find out how to implement it using mathematics. Finally we will implement this idea using Object Oriented Programming in JavaScript. More…

Escaping HTML in Java


HTML uses some special characters to control how a page is displayed. These characters need to be escaped before placed on a page if they are to be displayed as part of the page content (and not just to control how the page appears). This is similar to the way double quote characters in a C/C++ string have to be escaped in order for code to compile properly. Therefore, a web application needs to escape all user input before rendering HTML back to the user.

There are 2 ways to deal with this, both with their strengths and weaknesses:

  1. Filtering – throwing away all characters that are not in the set of acceptable input characters.
  2. Escaping special characters – escaping all special characters by turning them into their respective HTML entities.

In this short article we will cover the second way. We note however that in order to effectively protect against Cross Site Scripting(XSS) vulnerabilities a combination of both approaches may need to be used. Automated testing are the key to ensuring your application handles all input correctly, preventing malicious acts. More…