The localStorage
object in Internet Explorer 11 (Windows 7 build) contains string representations of certain functions instead of native calls as you would expe
Turns out this is a problem in the base version of IE11 (11.0.9600.16428) for Windows 7 SP1.
After installing a patch to update to 11.0.9600.16476 (update version 11.0.2 - KB2898785) the issue gets resolved. Links to other versions of Windows (32-bit etc.) can be found at the bottom of the patch download page.
My localStorage returned undefined and I couldn't figure out why - until I realized that it was because I was running the HTML-page (with the localStorage script) directly from my computer (file:///C:/Users/...). When I accessed the page from a server/localhost instead it localStorage was indeed defined and worked.
It's not just IE11's fault.
Probably WEINRE is injected into the page. It hooks into several system functions to provide Developer Tools functionality, but IE11 interprets assignments to the localStorage
and sessionStorage
properties wrong, and converts the hook functions into strings, as if they were the data that is going to be stored.
There's a comment in the apache/cordova-weinre repo which says:
#In IE we should not override standard storage functions because IE does it incorrectly - all values that set as
# storage properties (e.g. localStorage.setItem = function()[...]) are cast to String.
# That leads to "Function expected" exception when any of overridden function is called.
object[property] = hookedFunction unless navigator.userAgent.match(/MSIE/i) and (object is localStorage or object is sessionStorage)
Looks like it's either an old version of WEINRE being used, or this change hasn't been officially released (it's been there since 2013).
In addition to the already excellent answers here, I'd like to add another observation. In my case, the NTFS permissions on the Windows %LOCALAPPDATA% directory structure were somehow broken.
To diagnose this issue. I created a new Windows account (profile), which worked fine with the localStorage,so then I painstakingly traversed the respective %LOCALAPPDATA%\Microsoft\Internet Explorer trees looking for discrepancies.
I found this gem:
C:\Users\User\AppData\Local\Microsoft>icacls "Internet Explorer"
Internet Explorer Everyone:(F)
I have NO idea how the permissions were set wide open!
Worse, all of the subdirectories has all permissions off. No wonder the DOMStore was inaccessible!
The working permissions from the other account were:
NT AUTHORITY\SYSTEM:(OI)(CI)(F)
BUILTIN\Administrators:(OI)(CI)(F)
my-pc\test:(OI)(CI)(F)
Which matched the permissions of the parent directory.
So, in a fit of laziness, I fixed the problem by having all directories "Internet Explorer" and under inherit the permissions. The RIGHT thing to do would be to manually apply each permission and not rely on the inherit function. But one thing to check is the NTFS permissions of %LOCALAPPDATA%\Microsoft\Internet Explorer if you experience this issue. If DOMStore has broken permissions, all attempts to access localStorage will be met with Access Denied.