Resolving the z-index problem in Android 2.x Browser

One of the alarming issues of the Android 2.x Browser is that it does not respect the z-index of input elements, this issue is described here in details:

This issue can actually be very blocker to you if your mobile web application contains many openers that utilize the z-index CSS property in order to appear on the top of the active mobile view. This is because when the application’s opener is active and due to this bug, you can find the underlying mobile view input elements highlighted (focused) on the top of the opener as shown in the figure below.

In order to resolve this issue, I applied the following solution that works with me:
1. When a new opener is opened:
All of the *relevant* underlying input elements inside the view must be disabled. Doing this fix will disable the keyboard interaction with the underlying input elements and in the same time will not allow these input elements to be *focused*.

2. When the opener is closed:
All of the disabled input elements in the first step can be re-enabled again.

The solution looks complex, however, it can help if you have a similar situation.

JavaScript Variable Scope confusion for Java Developers

Sometimes, the Java developers that are new to the JavaScript world have a confusion regarding the variable scoping in JavaScript. Let’s see an example that will illustrate this confusion, consider that we are having the following Simple JavaScript code:

var someVar = 0;

    var someVar = 100;


Some of the new JavaScript developers (from Java background) will expect that the result of the someVar will be 0, because the defined someVar variable inside the inline block will be ignored once the inline block ends.

In fact, the end result will be 100, This is because JavaScript does not have the concept of Java block scopes, JavaScript has only two scopes:
1. Global Scope.
2. Local Scope which is applied ONLY on the function(s) level (A single function or functions inside function) NOT on any other type of block(s) level (such as loops and inline blocks).

To be able to understand JavaScript local scope, Let’s introduce a new function to our original example:

    var someVar = 100;
    //someVar will be visible everyWhere ...

function someFunction() {
    var someVar = 10; 
    //someVar will be visible only here as 10 ...


The result will be:


someFunction defines a someVar variable and initializes it to 10, the someVar variable will be visible as long as we are in the someFunction‘s scope, when the someFunction ends, the someVar‘s function variable will not be available anymore, this is why the second alert will produce 100 which is the original value of someVar that is defined in the Global scope.

Checking the Local Storage limits across the browsers

One of the issues you may face during your daily job (if you are a web developer) is how to check the limits of the Local Storage across the different browsers. This is because there is no unified fixed storage quota for local storage across all the browsers, for example, Chrome local storage quota is 2.5 MB. In Firefox, it is 5 MB and in IE, it is 10 MB.

In order to check if the local storage reaches its maximum quota, it will not be efficient to depend on the mentioned quota sizes on every browser, other than this, I prefer to do this programmatic-ally as shown in the following JavaScript function:

function saveInLocalStorage(name, value) {
    try { = value;
        return true;
    } catch (e) {
        return false;

Using saveInLocalStorage method, you can safely store your local storage entry, and if saveInLocalStorage method returns false, this is an indicator that the browser’s local storage maximum quota is reached, and you will need to show the user an error message asking him to free some of the saved entries in the local storage.

These are my thoughts regarding how to implement this requirement, if you have other thoughts, let me know.