L'uso di LocalStorage su iPhone con iOS 7 genera questo errore. Ho cercato un risolutore, ma considerando che non sto nemmeno navigando in privato, nulla è rilevante.

Non capisco perché localStorage sia disabilitato per impostazione predefinita in iOS 7, ma sembra che lo sia? Ho testato anche su altri siti Web, ma senza fortuna. Ho anche provato a provarlo usando questo sito Web: http://arty.name/localstorage.html , ma non sembra che stia salvando nulla per qualche strana ragione.

Qualcuno ha avuto lo stesso problema, solo loro hanno avuto fortuna risolverlo? Devo cambiare il mio metodo di archiviazione?

Ho provato a eseguirne il debug archiviando solo poche righe di informazioni, ma senza risultati. Ho usato la localStorage.setItem()funzione standard per salvare.

Ciò può verificarsi quando Safari è in modalità di navigazione privata. Durante la navigazione privata, l'archiviazione locale non è affatto disponibile.

Una soluzione è avvisare l'utente che l'app ha bisogno della modalità non privata per funzionare.

AGGIORNAMENTO: questo problema è stato risolto in Safari 11 , quindi il comportamento è ora allineato con altri browser.

Come menzionato in altre risposte, otterrai sempre QuotaExceededError in modalità Browser privato Safari su iOS e OS X quando localStorage.setItem(o sessionStorage.setItem) viene chiamato.

Una soluzione consiste nell'eseguire un controllo try / catch o Modernizr in ciascuna istanza di utilizzo setItem.

Tuttavia, se si desidera uno shim che interrompa semplicemente questo errore a livello globale, per impedire la rottura del resto del JavaScript, è possibile utilizzare questo:

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.');
    }
}

Uso questa semplice funzione, che restituisce trueo false, per verificare la disponibilità di LocalStorage:

isLocalStorageNameSupported = function() {
    var testKey = 'test', storage = window.sessionStorage;
    try {
        storage.setItem(testKey, '1');
        storage.removeItem(testKey);
        return true;
    } catch (error) {
        return false;
    }
}

Ora puoi verificare la localStorage.setItem()disponibilità prima di usarlo. Esempio:

if ( isLocalStorageNameSupported() ) {
    // can use localStorage.setItem('item','value')
} else {
    // can't use localStorage.setItem('item','value')
}

Mi è capitato di correre con lo stesso problema in iOS 7 (con alcuni dispositivi senza simulatori).

Sembra che Safari in iOS 7 abbia una quota di archiviazione inferiore, che a quanto pare è raggiunta con un registro cronologico lungo.

Immagino che la migliore pratica sarà quella di catturare l'eccezione.

Il progetto Modernizr ha una patch semplice, dovresti provare qualcosa di simile: https://github.com/Modernizr/Modernizr/blob/master/feature-detects/storage/localstorage.js

Ecco una soluzione estesa basata sulla risposta di DrewT sopra che utilizza i cookie se localStorage non è disponibile. Utilizza la libreria docCookies di Mozilla :

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;
}

Nella tua fonte, basta usare:

localStorageSet( 'foobar', 'yes' );
...
var foo = localStorageGet( 'foobar' );
...

Come già spiegato in altre risposte, in modalità Navigazione privata Safari genererà sempre questa eccezione quando si tenta di salvare i dati localStorage.setItem().

Per risolvere questo problema, ho scritto un localStorage falso che imita localStorage, sia metodi che eventi.

Archivio locale falso: https://gist.github.com/engelfrost/fd707819658f72b42f55

Questa probabilmente non è una buona soluzione generale al problema. Questa è stata una buona soluzione per il mio scenario, in cui l'alternativa consisterebbe in importanti riscritture su un'applicazione già esistente.

Aggiornamento (01/11/2016)

Stavo usando AmplifyJS menzionato di seguito per aggirare questo problema. Tuttavia, per Safari nella navigazione privata, stava ricadendo in una memoria basata sulla memoria. Nel mio caso, non era appropriato perché significa che l'archiviazione viene cancellata durante l'aggiornamento, anche se l'utente è ancora in navigazione privata.

Inoltre, ho notato un numero di utenti che navigano sempre in modalità privata su iOS Safari. Per tale motivo, un migliore fallback per Safari è l'uso dei cookie (se disponibili). Per impostazione predefinita, i cookie sono ancora accessibili anche nella navigazione privata. Naturalmente, vengono cancellati all'uscita dalla navigazione privata, ma non vengono cancellati all'aggiornamento.

Ho trovato la libreria local-storage-fallback . Dalla documentazione:

Scopo

Con le impostazioni del browser come "Navigazione privata" è diventato un problema fare affidamento su un window.localStorage funzionante, anche nei browser più recenti. Anche se può esistere, genererà eccezioni quando si tenta di utilizzare setItem o getItem. Questo modulo eseguirà i controlli appropriati per vedere quale meccanismo di archiviazione del browser potrebbe essere disponibile e quindi esporlo. Utilizza la stessa API di localStorage, quindi nella maggior parte dei casi dovrebbe funzionare come sostituzione drop-in.

Attenzione ai gotcha:

• CookieStorage ha limiti di archiviazione. Stai attento qui.
• MemoryStorage non persisterà tra i caricamenti di pagina. Questo è più o meno uno stop-gap per prevenire arresti anomali della pagina, ma può essere sufficiente per i siti Web che non eseguono il caricamento completo della pagina.

TL; DR:

Usa local-storage-fallback (API unificata con .getItem(prop)e .setItem(prop, val)):

Controllare e utilizzare l'adattatore di archiviazione appropriato per il browser (localStorage, sessionStorage, cookies, memory)

Risposta originale

Per aggiungere risposte precedenti, una possibile soluzione alternativa sarebbe quella di modificare il metodo di archiviazione. Ci sono alcune librerie come AmplifyJS e PersistJS che possono aiutare. Entrambe le librerie consentono l'archiviazione persistente sul lato client attraverso diversi backend.

Per AmplifyJS

memoria locale

• IE 8+
• Firefox 3.5+
• Safari 4+
• Cromo
• Opera 10.5+
• iPhone 2+
• Android 2+

sessionStorage

• IE 8+
• Firefox 2+
• Safari 4+
• Cromo
• Opera 10.5+
• iPhone 2+
• Android 2+

globalStorage

• Firefox 2+

dati utente

• IE 5 - 7
• userData esiste anche nelle versioni più recenti di IE, ma a causa di stranezze nell'implementazione di IE 9, non registriamo userData se localStorage è supportato.

memoria

• Un archivio in memoria viene fornito come fallback se nessuno degli altri tipi di archiviazione è disponibile.

Per PersistentJS

• flash: memoria permanente Flash 8.
• gears: archiviazione persistente basata su Google Gears.
• localstorage: archiviazione bozze HTML5.
• globalstorage: archiviazione bozze HTML5 (vecchie specifiche).
• ovvero: comportamenti dei dati utente di Internet Explorer.
• cookie: archiviazione persistente basata su cookie.

Offrono un livello di astrazione in modo da non doverti preoccupare di scegliere il tipo di archiviazione. Tieni presente che potrebbero esserci alcune limitazioni (come i limiti di dimensione) a seconda del tipo di archiviazione. In questo momento, sto usando AmplifyJS, ma devo ancora fare altri test su iOS 7 / Safari / ecc. per vedere se risolve effettivamente il problema.

Nell'aprile 2017 una patch è stata fusa in Safari, quindi allineata con gli altri browser. Questo è stato rilasciato con Safari 11.

https://bugs.webkit.org/show_bug.cgi?id=157010

Questa domanda e risposta mi hanno aiutato a risolvere un problema specifico con l'iscrizione di nuovi utenti in Parse.

Poiché la funzione signUp (attrs, options) utilizza l'archiviazione locale per rendere persistente la sessione, se un utente è in modalità di navigazione privata, genera "QuotaExceededError: DOM Eccezione 22: è stato effettuato un tentativo di aggiungere qualcosa all'archiviazione che ha superato la quota". l'eccezione e le funzioni di successo / errore non vengono mai chiamate.

Nel mio caso, poiché la funzione di errore non viene mai chiamata, inizialmente sembrava essere un problema con l'attivazione dell'evento click sull'invio o il reindirizzamento definito in caso di successo dell'iscrizione.

Includere un avviso per gli utenti ha risolto il problema.

Parse Javascript SDK Reference https://parse.com/docs/js/api/classes/Parse.User.html#methods_signUp

Iscriviti un nuovo utente con un nome utente (o e-mail) e una password. Ciò creerà un nuovo Parse.User sul server e persisterà anche la sessione in localStorage in modo da poter accedere all'utente utilizzando {@link #current}.