We have an application that starts via Click Once in the browser. Since Chromium Edge, Click Once isn't enabled by default. You can enable this setting via edge://flags/#edge-click-once.
I would like to detect if this setting is enabled. If not i would like to direct them to a support page with instructions to enable it.
I don't have access to clients browser in anyway. So I would like to detect this via JavaScript.
I think the flags can't be accessed through js, because js codes can be executed in any browsers. We can't only target the features in a certain browser. I also searched a lot and find no way. Maybe Extension can do this, but I think that will take a lot of effort to research.
As this feature is not enabled by Edge Chromium by default, I think the easiest workaround is to detect the browser version, if Edge Chromium, then remind the user to check if the feature is enabled:
var checkbrowser = (function(agent) {
if (agent.indexOf("edg") > -1) { //check if Edge Chromium
return "the page of showing how to enable clickonce support";
} else {
return "not Edge Chromium"
}
})(window.navigator.userAgent.toLowerCase());
document.body.innerHTML = checkbrowser;
Besides, if your application is used in an enterprise and someone has access to the group policy, you can also suggest IT department to set this group policy: ClickOnceEnabled to enable clickonce in Edge Chromium.
Using LocalStorage on iPhone with iOS 7 throws this error. I've been looking around for a resolvant, but considering I'm not even browsing in private, nothing is relevant.
I don't understand why localStorage would be disabled by default in iOS 7, but it seems it is? I've tested on other websites as well, but with no luck. I even tried testing it using this website: http://arty.name/localstorage.html, but it doesn't seem like it's saving anything at all for some weird reason.
Has anyone had the same problem, only they've had luck fixing it? Should I switch my storage method?
I tried hard-debugging it by only storing a few lines of information, but to no avail. I used the standard localStorage.setItem() function to save.
This can occur when Safari is in private mode browsing. While in private browsing, local storage is not available at all.
One solution is to warn the user that the app needs non-private mode to work.
UPDATE: This has been fixed in Safari 11, so the behaviour is now aligned with other browsers.
As mentioned in other answers, you'll always get the QuotaExceededError in Safari Private Browser Mode on both iOS and OS X when localStorage.setItem (or sessionStorage.setItem) is called.
One solution is to do a try/catch or Modernizr check in each instance of using setItem.
However if you want a shim that simply globally stops this error being thrown, to prevent the rest of your JavaScript from breaking, you can use this:
https://gist.github.com/philfreo/68ea3cd980d72383c951
// Safari, in Private Browsing Mode, looks like it supports localStorage but all calls to setItem
// throw QuotaExceededError. We're going to detect this and just silently drop any calls to setItem
// to avoid the entire page breaking, without having to do a check at each usage of Storage.
if (typeof localStorage === 'object') {
try {
localStorage.setItem('localStorage', 1);
localStorage.removeItem('localStorage');
} catch (e) {
Storage.prototype._setItem = Storage.prototype.setItem;
Storage.prototype.setItem = function() {};
alert('Your web browser does not support storing settings locally. In Safari, the most common cause of this is using "Private Browsing Mode". Some settings may not save or some features may not work properly for you.');
}
}
I use this simple function, which returns true or false, to test for localStorage availablity:
isLocalStorageNameSupported = function() {
var testKey = 'test', storage = window.sessionStorage;
try {
storage.setItem(testKey, '1');
storage.removeItem(testKey);
return true;
} catch (error) {
return false;
}
}
Now you can test for localStorage.setItem() availability before using it. Example:
if ( isLocalStorageNameSupported() ) {
// can use localStorage.setItem('item','value')
} else {
// can't use localStorage.setItem('item','value')
}
I happened to run with the same issue in iOS 7 (with some devices no simulators).
Looks like Safari in iOS 7 has a lower storage quota, which apparently is reached by having a long history log.
I guess the best practice will be to catch the exception.
The Modernizr project has an easy patch, you should try something similar: https://github.com/Modernizr/Modernizr/blob/master/feature-detects/storage/localstorage.js
Here is an expanded solution based on DrewT's answer above that uses cookies if localStorage is not available. It uses Mozilla's docCookies library:
function localStorageGet( pKey ) {
if( localStorageSupported() ) {
return localStorage[pKey];
} else {
return docCookies.getItem( 'localstorage.'+pKey );
}
}
function localStorageSet( pKey, pValue ) {
if( localStorageSupported() ) {
localStorage[pKey] = pValue;
} else {
docCookies.setItem( 'localstorage.'+pKey, pValue );
}
}
// global to cache value
var gStorageSupported = undefined;
function localStorageSupported() {
var testKey = 'test', storage = window.sessionStorage;
if( gStorageSupported === undefined ) {
try {
storage.setItem(testKey, '1');
storage.removeItem(testKey);
gStorageSupported = true;
} catch (error) {
gStorageSupported = false;
}
}
return gStorageSupported;
}
In your source, just use:
localStorageSet( 'foobar', 'yes' );
...
var foo = localStorageGet( 'foobar' );
...
As already explained in other answers, when in Private Browsing mode Safari will always throw this exception when trying to save data with localStorage.setItem() .
To fix this I wrote a fake localStorage that mimics localStorage, both methods and events.
Fake localStorage: https://gist.github.com/engelfrost/fd707819658f72b42f55
This is probably not a good general solution to the problem. This was a good solution for my scenario, where the alternative would be major re-writes to an already existing application.
Update (2016-11-01)
I was using AmplifyJS mentioned below to work around this issue. However, for Safari in Private browsing, it was falling back to a memory-based storage. In my case, it was not appropriate because it means the storage is cleared on refresh, even if the user is still in private browsing.
Also, I have noticed a number of users who are always browsing in Private mode on iOS Safari. For that reason, a better fallback for Safari is to use cookies (if available). By default, cookies are still accessible even in private browsing. Of course, they are cleared when exiting the private browsing, but they are not cleared on refresh.
I found the local-storage-fallback library. From the documentation:
Purpose
With browser settings like "Private Browsing" it has become a problem to rely on a working window.localStorage, even in newer browsers. Even though it may exist, it will throw exceptions when trying to use setItem or getItem. This module will run appropriate checks to see what browser storage mechanism might be available, and then expose it. It uses the same API as localStorage so it should work as a drop-in replacement in most cases.
Beware of the gotchas:
CookieStorage has storage limits. Be careful here.
MemoryStorage will not persist between page loads. This is more or less a stop-gap to prevent page crashes, but may be sufficient for websites that don't do full page loads.
TL;DR:
Use local-storage-fallback (unified API with .getItem(prop) and .setItem(prop, val)):
Check and use appropriate storage adapter for browser (localStorage, sessionStorage, cookies, memory)
Original answer
To add upon previous answers, one possible workaround would be to change the storage method. There are a few librairies such as AmplifyJS and PersistJS which can help. Both libs allow persistent client-side storage through several backends.
For AmplifyJS
localStorage
IE 8+
Firefox 3.5+
Safari 4+
Chrome
Opera 10.5+
iPhone 2+
Android 2+
sessionStorage
IE 8+
Firefox 2+
Safari 4+
Chrome
Opera 10.5+
iPhone 2+
Android 2+
globalStorage
Firefox 2+
userData
IE 5 - 7
userData exists in newer versions of IE as well, but due to quirks in IE 9's implementation, we don't register userData if localStorage
is supported.
memory
An in-memory store is provided as a fallback if none of the other storage types are available.
For PersistentJS
flash: Flash 8 persistent storage.
gears: Google Gears-based persistent storage.
localstorage: HTML5 draft storage.
globalstorage: HTML5 draft storage (old spec).
ie: Internet Explorer userdata behaviors.
cookie: Cookie-based persistent storage.
They offer an abstraction layer so you don't have to worry about choosing the storage type. Keep in mind there might be some limitations (such as size limits) depending on the storage type though. Right now, I am using AmplifyJS, but I still have to do some more testing on iOS 7/Safari/etc. to see if it actually solves the problem.
In April 2017 a patch was merged into Safari, so it aligned with the other browsers. This was released with Safari 11.
https://bugs.webkit.org/show_bug.cgi?id=157010
This question and answer helped me solve a specific problem with signing up new users in Parse.
Because the signUp( attrs, options ) function uses local storage to persist the session, if a user is in private browsing mode it throws the "QuotaExceededError: DOM Exception 22: An attempt was made to add something to storage that exceeded the quota." exception and the success/error functions are never called.
In my case, because the error function is never called it initially appeared to be an issue with firing the click event on the submit or the redirect defined on success of sign up.
Including a warning for users resolved the issue.
Parse Javascript SDK Reference
https://parse.com/docs/js/api/classes/Parse.User.html#methods_signUp
Signs up a new user with a username (or email) and password. This will create a new Parse.User on the server, and also persist the session in localStorage so that you can access the user using {#link #current}.
While testing our site with IE, we were disabling/enabling the cookies from the privacy settings tab. But this not does seem to work as expected. (for the first time it worked, and from then on,it stopped working).Chrome and Firefox seem to work fine though.
the logic we have written to check if cookies are enabled/disabled is as follows:
We try to create a test cookie using document.cookie(we have not specified any domain nor an expiry date). If the cookie can be created, then we say the cookies are enabled,else they are disabled.We then go ahead and remove the test cookie. The problem in IE is that,even if the cookies are enabled,we are not able to create the test cookie/if they are disabled, we are able to create the test cookie. It happens both the ways.
any thoughts/ideas?
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?
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.
We hit a similar issue because we ran CCleaner on the machine.
To solve:
Internet Options -> Browsing History -> Delete:
Make sure to check all options except the very first one (Preserve Favorite website data).
We were able to fix, then reproduce this issue by using CCleaner again, then fix again.
Go to this site for more information: http://grekai.wordpress.com/2013/02/24/localstorage-the-system-cannot-find-the-path-specified/
I am having a hard time figuring out a solution for my problem. Here's a code snippet:
var ans = prompt("Mot de passe", '');
if (ans != '' && ans != null)
__doPostBack('__Page', ans);
else
window.location = "../Erreurs/NotAuthorized.aspx";
This code works really great with Internet Explorer 9. But my client is exclusively working with Internet Explorer 8 so I tested it with ieTester in IE8. But the problem is that the prompt doesn't show and it automatically redirect because the input had an empty string ('').
So how do I fix this to work with Internet Explorer 8?
IE has an setting in Internet Options to allow or deny prompt().
(source: adamhaskell.net)
By default in IE8, this setting is off. Consequently, calls to prompt() are ignored and "" is returned by them.
You shouldn't use prompt() anyway. Use a form.
It looks like a security thing specific to IE- 8 for sure, I don't have other versions to test. Calling prompt() produces a warning about a scripted window asking for information. I can click to allow and after refreshing the page, the prompt box appears as expected.
If you are going to insist on using prompt(), you will probably have to stipulate that security settings on the target machines are configured to allow it.
Microsoft developer website tells us that "prompt()" is deprecated and now normally blocked for security reasons:
"By default, this method is blocked by the information bar in the Internet zone. This helps prevent malicious sites from initiating spoofing attacks. "
See http://msdn.microsoft.com/en-us/library/ms536673.aspx
From this report it looks like it's a known bug in IETester?
http://www.my-debugbar.com/forum/t294-Javascript-Alerts.html