a brief history of detecting local storage

gistfile1.md

A timeline of the last four years of detecting good old window.localStorage.

---

Jan Lenhart, bless his heart contributed the first patch for support:

October 2009: 5059daa

(typeof window.localStorage != 'undefined')

Simplicifations

November 2009: 15020e7

!!window.localStorage

If cookies disabled in FF, exception. Softer detect

December 2009: 1e0ba91

!!('localStorage' in window)

If DOM storage disabled in IE, window.localStorage is present but === null.

January 2010: d8947c9

(localStorage in window) && window[localStorage] !== null

FF with dom.storage.enabled = false throws exceptions

July 2010: ef2c47

try {
  return ('localStorage' in window) && window[localstorage] !== null;
} catch(e) {
  return false;
}

more shit because of FF exceptions

December 2010: c630c39

try {
    return !!localStorage.getItem;
} catch(e) {
    return false;
}

iOS private browsing fucks everyone!!!

October 2011: 5e2fa0e

try {
    return !!localStorage.getItem('getItem');
} catch(e) {
    return false;
}

stronger full capability test for localstorage with iOS private browsing protection

October 2011: a93625c

try {
    localStorage.setItem(mod, mod);
    localStorage.removeItem(mod);
    return true;
} catch(e) {
    return false;
}

by way of interest, there's a slight difference in the current version of the code put in the comment above from mpavel (commented on Apr 18, 2016) regarding the Web Storage API 'Basic Concepts' page section entitled:
"Here is a function that detects whether localStorage is both supported and available:"
mpavel in April 2016 put this:

catch(e) { return false; }

today in December 2017 this snippet reads thus:
catch(e) { return e instanceof DOMException && ( // everything except Firefox e.code === 22 || // Firefox e.code === 1014 || // test name field too, because code might not be present // everything except Firefox e.name === 'QuotaExceededError' || // Firefox e.name === 'NS_ERROR_DOM_QUOTA_REACHED') && // acknowledge QuotaExceededError only if there's something already stored storage.length !== 0; }

@tigr5

like this?

function storageAvailable(type) {
	try {
		var storage = window[type],
			x = '__storage_test__';
		storage.setItem(x, x);
		storage.removeItem(x);
		return true;
	}
	catch(e) {
		return e instanceof DOMException && (
			e.code === 22 || e.code === 1014 ||
			e.name === 'QuotaExceededError' ||
			e.name === 'NS_ERROR_DOM_QUOTA_REACHED'
		) && storage.length !== 0;
	}
}

The first lines inside the try block might already fail with an exception:

var storage = window[type], // could throw if storage is disabled (Firefox)
    x = '__storage_test__';
// storage might be null here.... (Internet Explorer)
storage.setItem(x, x);  // would throw if storage is null

Just read back in this gist. FF will in some cases throw an exception if you touch window.localStorage.... IE might give you a null object... So I don't see how the extra checks for the exception type help. In fact I think they actively break the code.

The way I approach it, if simply setting and removing an item from storage fails in any way then storage is not available.

I stand by my original version. I have given up on maintaining the MDN page. People keep coming by and 'fixing' the code sample. I have even seen people change it to samples that don't even run at all or always return true etc. My original sample works fine and does not need those extra lines imho. In fact the code becomes less reliable because of those extra lines.

@Download The modified catch block will still return false except when the caught error happens to be "over quota error" (which is checked in four different ways), which means that the storage system is actually available, but just exhausted, and thus the (arguably) correct answer is still true

Does this gist apply equally to sessionStorage?

Yeah, in fact I think it does. Which is why that storageAvailable function accepts a type parameter. So you can use it for both localStorage and sessionStorage.

In case you want to save some bytes, instead of:

    localStorage.setItem(mod, mod);
    localStorage.removeItem(mod);

you can do this:

    localStorage.x = 1;
    delete localStorage.x;

Can anyone provide insight/their opinion on what are good uses cases for sessionStorage? https://stackoverflow.com/questions/8498357/when-should-i-use-html5-sessionstorage

@devinrhode2 I think sessionStorage is great for any data you want to share across pages and tabs for the duration of the browsing session. It will be wiped as soon as the browser closes.

@devinrhode2 I think sessionStorage is great for any data you want to share across pages and tabs for the duration of the browsing session. It will be wiped as soon as the browser closes.

Wrong.
"Opening multiple tabs/windows with the same URL creates sessionStorage for each tab/window." (source: mdn)

I have tried this !!('localStorage' in window) === true

and ('localStorage' in window)=== true 🙏 very simple