I'm working on a client issue where Modernizr unexpectedly does not detect the support for the localStorage
object in Internet Explorer 9. My page correctly uses the HTML 5 doctype (<!DOCTYPE html>
) and the developer tools report the page has a Browser Mode of IE9 and a Document Mode of IE9 standards so I would expect this to work.
I've debugged into the following try
/catch
block in Modernizr and discovered a JavaScript error is thrown as soon as the localStorage
object is accessed.
tests['localstorage'] = function() {
try {
localStorage.setItem(mod, mod);
localStorage.removeItem(mod);
return true;
} catch(e) {
return false;
}
};
On some machines the message of the JavaScript error is The system cannot find the file specified.
. On others it is just Invalid argument.
and Internet Explorer blocks for exactly 5 minutes before it throws the error.
What is causing accessing the localStorage
object to throw an error here on Internet Explorer?
IE also supports localStorage from IE8 but it does not support localStorage in IE7 and previous versions. Cookies are small text files stored by browsers allowing for a max of 4KB while with localStorage we can store Mbs of localStorage data.
Supposedly, window. localStorage makes the localStorage faster to be found than just writing localStorage. Storing a reference to it on a variable makes it even faster. Anyway, these improvements are negligible on modern browsers.
Storing images As we established above, localStorage only supports strings, so what we need to do here is turn the image into a Data URL. One way to do this for an image, is to load into a canvas element. Then, with a canvas , you can read out the current visual representation in a canvas as a Data URL.
I've discovered if the lowest level subdomain matches one of the reserved device names as documented at Restrictions on the File Mask and File Name Properties on Internet Explorer then accessing the localStorage
object will throw an error.
This problem is likely happening because internally Internet Explorer is attempting to access the file system using a reserved device name when accessing the localStorage
object in order to satisfy the Storage
object initialization steps.
It's certainly very much an edge case but if your page is comes from a server whose lowest level subdomain is exactly any of con
, prn
, aux
, clock$
, nul
, com1
, com2
, com3
, com4
, com5
, com6
, com7
, com8
, com9
, lpt1
, lpt2
, lpt3
, lpt4
, lpt5
, lpt6
, lpt7
, lpt8
, or lpt9
(e.g. http://prn.example.com
) then this could well the reason why you are seeing this problem.
Choosing a lower level subdomain that wasn't a reserved device name in this situation solved the problem.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With