LocalStorage and Safari Weirdness

One of the technologies that has been intriguing to me for a while has been LocalStorage on the web browser. One of my first adventures into using persistent storage other than cookies on a web browser was the short-lived HTML 5 standard of the webSQL database. It turns out that it was simply a SQL Lite database that was accessible via JavaScript in all the WebKit browsers as well as Firefox. However, Internet Explorer did not implement this functionality, and the webSQL standard was soon dropped from the HTML 5 standard itself, leaving only the LocalStorage key/value storage mechanism.

With the advent of the now hugely popular NoSQL databases such as MongoDB as well as Redis and others, the power of a key/value store in the browser has become immensely evident. In addition, with LocalStorage, you can be assured that every major browser supports it, even Internet Explorer 8 and newer. As a result, you would take a look at the W3Schools site on LocalStorage and assume that you can do something simple like:

if (typeof Storage !== "undefined") {
    localStorage.setItem("key", "value");
}

While this will work in all browsers, there are some scenarios that render this check useless. The most important of all to consider is Private Browsing in Safari across all devices and operating systems. It turns out that when you enable Private Browsing in Safari, the Storage object is still defined, but when you go to actually use localStorage it will throw an exception that will completely derail the rest of the JavaScript on your website. In order to be absolutely sure whether you can use localStorage on a particular browser, you should use something similar to the following to detect its availabiliy:

var useLocalStorage = false;

try {
    if (typeof Storage !== "undefined") {
        useLocalStorage = true;
        localStorage.setItem("key", "value");
    }
} catch (e) {
    useLocalStorage = false;
}

if (useLocalStorage) {
	// Do your localStorage operations here
}

Related Posts

Apr 29, 2014
2 minutes

Avoid jQuery.bind()

When chasing down performance issues, you never know what kind of problems you will find. I was looking for something that would cause jitter when scrolling on the page. After looking at the custom code that runs on every scroll event, I still had not found a reason for the jitter. Looking at the JavaScript CPU profile when scrolling in Chrome showed that there was an overwhelming majority of the time spent in a function in the Prototype JS library.

Jun 2, 2014
2 minutes

Defensive Development - Fail Fast or Go Home

Defensive Development is a programming practice that is frequently misunderstood, but is nevertheless a critical practice to follow when working in many environments. I have seen articles written that argue that defensive development simply causes nonsensical null checks to be written, and as a result of seeing people writing bad code defensively, argues that no one should practice defensive development. There are other articles that, like many things in software development, argue that you should always use defensive development for everything.

Jul 8, 2014
3 minutes

Always Use Automated Integration Testing

QA or Quality Assurance of a software project is often the area of software development that is most neglected. Typically developers avoid software testing like their lives depended on it. While a basic level of testing is required for a single scenario to validate that your code “works”, the level of testing that is required to ensure that all users have a good user experience across all targeted platforms is something that a developer seems to think is beneath them.