This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
navigator.storageEnabled property needed navigator.storageEnabled - return true when Storage enabled navigator.storageEnabled - return true when Storage disabled navigator.storageEnabled - old browsers return undefined
navigator.storageEnabled - return false when Storage disabled
Why would it be disabled?
>> Why would it be disabled? --- Firefox 3.0 RC1 about:config dom.storage.enabled (boolean) When disabled storage object throws exeption. --- IE 8.0 Tools/Internet Options/Disable DOM storage --- etc...
This is analogous (supporter by all browsers): https://developer.mozilla.org/en/DOM/window.navigator.cookieEnabled
Currently there is no way to check whether DOMStorage is turned on. By contrast, we can do about the cookies (window.navigator.cookieEnabled).
Created attachment 801 [details] explorer options
Created attachment 802 [details] firefox options
Disabling the storage in that way should just remove the attribute from the DOM, so that you can just do: if (window.Storage) { ... }
OK, try this using FF 3.6 with dom.storage.enabled = false. <!DOCTYPE html> <html> <body> <script> alert(window.Storage?'enabled':'disabled') </script> </body> </html> It alerts: enabled ...but sessionStorage throw exeption.
Is there a sentence in the draft specification, which says that the disabled DOMStorage window.Storage should return undefined? If not please because otherwise it will add to this mess in the browser.
* If not please add it because otherwise it will mess with this in the browser.
Actually, looking more closely at the Web Storage spec, wouldn't the right thing to do just be to try to use localStorage, and catch any resulting exceptions? As in: var storage; try { storage = window.localStorage; } catch { storage = new myCustomStorageSolution(); } ...or something? The reason for this is that in general, it is assumed that going forward localStorage will always work, except in situations where it will never work (e.g. in a sandbox). So if it is found to not work when it should, then it's a security exception (in the literal sense), and a security exception should be raised. I can add something saying that UAs should return null if they allow the user to just disable the feature, though, if you think that's needed. As far as I can tell, if the feature is disabled, it should be completely disabled, including the feature not appearing to be supported at all.
try...catch is not comfortable and causes some unnecessary code. It is much easier to use if(windows.Storage) or if (windows.Storage === null). If you can, please add it to the specifications. Working programmers will be simple and will not be problems with the crossing of browsers.
I think the best solution is a way from comment #1: navigator.storageEnabled - return true when Storage enabled navigator.storageEnabled - return false when Storage disabled navigator.storageEnabled - old browsers return undefined This is an analogy to the existing in all browsers: navigator.cookieEnabled
>> I can add something saying that UAs should return null Better is: return false because you can use if(window.Storage) { ... } forgetting that the null is casting to object and more to true. If null, you must: if(window.Storage && window.Storage !== null)
I've added a paragraph to the conformance section saying that if a feature is disabled, it has to be removed entirely, not just return null or throw an exception or whatnot.
Checked in as WHATWG revision r4693. Check-in comment: Make it clear that disabling a feature should truly remove it, not just stub it out. http://html5.org/tools/web-apps-tracker?from=4692&to=4693