Korzystanie z LocalStorage na iPhonie z iOS 7 powoduje zgłoszenie tego błędu. Rozglądałem się za rezolucją, ale biorąc pod uwagę, że nawet nie przeglądam na osobności, nic nie jest istotne.

Nie rozumiem, dlaczego localStorage byłby domyślnie wyłączony w iOS 7, ale wydaje się, że tak jest? Testowałem również na innych stronach internetowych, ale bez powodzenia. Próbowałem nawet przetestować go przy użyciu tej witryny: http://arty.name/localstorage.html , ale nie wydaje się, żeby coś w ogóle zapisywało z jakiegoś dziwnego powodu.

Czy ktoś miał ten sam problem, tylko czy udało mu się go naprawić? Czy powinienem zmienić metodę przechowywania?

Próbowałem go mocno debugować, przechowując tylko kilka wierszy informacji, ale bezskutecznie. Użyłem standardowej localStorage.setItem()funkcji do zapisania.

Może się to zdarzyć, gdy Safari jest w trybie prywatnym. Podczas przeglądania prywatnego pamięć lokalna nie jest w ogóle dostępna.

Jednym z rozwiązań jest ostrzeżenie użytkownika, że ​​aplikacja potrzebuje trybu nieprywatnego do działania.

AKTUALIZACJA: Zostało to naprawione w Safari 11 , więc zachowanie jest teraz dostosowane do innych przeglądarek.

Jak wspomniano w innych odpowiedziach, zawsze otrzymasz błąd QuotaExceededError w trybie prywatnej przeglądarki Safari na iOS i OS X, gdy localStorage.setItem(lubsessionStorage.setItem wywoływany jest ).

Jednym z rozwiązań jest sprawdzenie try / catch lub Modernizr przy każdym użyciu setItem.

Jeśli jednak chcesz zastosować podkładkę dystansową, która po prostu globalnie zatrzymuje generowanie tego błędu, aby zapobiec uszkodzeniu reszty kodu JavaScript, możesz użyć tego:

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

Korzystam z tej prostej funkcji, która zwraca truelub false, w celu przetestowania dostępności localStorage:

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

Teraz możesz przetestować localStorage.setItem()dostępność przed użyciem. Przykład:

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

Zdarzyło mi się działać z tym samym problemem w iOS 7 (na niektórych urządzeniach nie ma symulatorów).

Wygląda na to, że Safari w iOS 7 ma niższy limit miejsca, który najwyraźniej jest osiągnięty przez długi dziennik historii.

Chyba najlepszą praktyką będzie złapanie wyjątku.

Projekt Modernizr ma łatwą łatkę, powinieneś spróbować czegoś podobnego: https://github.com/Modernizr/Modernizr/blob/master/feature-detects/storage/localstorage.js

Oto rozszerzone rozwiązanie oparte na powyższej odpowiedzi DrewT, które wykorzystuje pliki cookie, jeśli localStorage nie jest dostępny. Korzysta z biblioteki docCookies Mozilli :

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

W swoim źródle po prostu użyj:

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

Jak już wyjaśniono w innych odpowiedziach, w trybie przeglądania prywatnego Safari zawsze zgłasza ten wyjątek przy próbie zapisania danych localStorage.setItem().

Aby to naprawić, napisałem fałszywy localStorage, który naśladuje localStorage, zarówno metody, jak i zdarzenia.

Fałszywy lokalny magazyn: https://gist.github.com/engelfrost/fd707819658f72b42f55

Prawdopodobnie nie jest to dobre ogólne rozwiązanie problemu. To było dobre rozwiązanie dla mojego scenariusza, w którym alternatywą byłoby poważne ponowne zapisanie do już istniejącej aplikacji.

Aktualizacja (01.11.2016)

Użyłem wspomnianego poniżej AmplifyJS do obejścia tego problemu. Jednak w przypadku przeglądarki Safari w trybie prywatnym wracała do pamięci opartej na pamięci. W moim przypadku nie było to właściwe, ponieważ oznacza to, że pamięć jest czyszczona podczas odświeżania, nawet jeśli użytkownik nadal korzysta z prywatnego przeglądania.

Zauważyłem również wielu użytkowników, którzy zawsze przeglądają w trybie prywatnym na iOS Safari. Z tego powodu lepszym rozwiązaniem dla Safari jest użycie plików cookie (jeśli są dostępne). Domyślnie pliki cookie są nadal dostępne nawet podczas prywatnego przeglądania. Oczywiście są one usuwane podczas wychodzenia z prywatnego przeglądania, ale nie są usuwane podczas odświeżania.

Znalazłem bibliotekę rezerwową lokalnego magazynu . Z dokumentacji:

Cel, powód

Przy ustawieniach przeglądarki, takich jak „Prywatne przeglądanie”, problemem stało się poleganie na działającym window.localStorage, nawet w nowszych przeglądarkach. Mimo że może istnieć, zgłasza wyjątki podczas próby użycia setItem lub getItem. Ten moduł uruchomi odpowiednie kontrole, aby sprawdzić, jaki mechanizm pamięci przeglądarki może być dostępny, a następnie go ujawni. Używa tego samego interfejsu API co localStorage, więc w większości przypadków powinien działać jako zastępczy drop-in.

Uwaga na gotchas:

• CookieStorage ma limity przechowywania. Uważaj tutaj.
• MemoryStorage nie będzie trwał między ładowaniami stron. Jest to mniej więcej przerwa, aby zapobiec awariom strony, ale może być wystarczająca w przypadku witryn, które nie ładują całej strony.

TL; DR:

Użyj rezerwy lokalnej pamięci masowej (ujednolicony interfejs API z .getItem(prop)i .setItem(prop, val)):

Sprawdź i użyj odpowiedniego adaptera pamięci dla przeglądarki (localStorage, sessionStorage, cookies, pamięć)

Oryginalna odpowiedź

Aby dodać poprzednie odpowiedzi, jednym z możliwych obejść może być zmiana metody przechowywania. Istnieje kilka librairies, takich jak AmplifyJS i PersistJS które mogą pomóc. Obie biblioteki pozwalają na trwałe przechowywanie po stronie klienta przez kilka backendów.

Dla AmplifyJS

Lokalny magazyn

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

sessionStorage

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

globalStorage

• Firefox 2+

dane użytkownika

• IE 5 - 7
• userData istnieje również w nowszych wersjach IE, ale z powodu dziwactw w implementacji IE 9, nie rejestrujemy userData, jeśli jest obsługiwany localStorage.

pamięć

• Magazyn w pamięci jest zastępczy, jeśli żaden z pozostałych typów pamięci nie jest dostępny.

For PersistentJS

• flash: Pamięć trwała Flash 8.
• koła zębate: trwałe miejsce do przechowywania oparte na Google Gears.
• localstorage: Przechowywanie wersji roboczej HTML5.
• globalstorage: Przechowywanie wersji roboczej HTML5 (stara specyfikacja).
• tj. zachowania danych użytkownika w Internet Explorerze.
• cookie: trwałe przechowywanie na podstawie plików cookie.

Oferują warstwę abstrakcji, więc nie musisz się martwić o wybór rodzaju pamięci. Pamiętaj jednak, że mogą istnieć pewne ograniczenia (takie jak limity wielkości) w zależności od rodzaju pamięci. W tej chwili używam AmplifyJS, ale nadal muszę wykonać więcej testów na iOS 7 / Safari / etc. aby sprawdzić, czy to faktycznie rozwiązuje problem.

W kwietniu 2017 r. Łatka została połączona z Safari, więc była zgodna z innymi przeglądarkami. Zostało to wydane wraz z Safari 11.

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

To pytanie i odpowiedź pomogły mi rozwiązać konkretny problem z rejestracją nowych użytkowników w Parse.

Ponieważ funkcja signUp (attrs, options) używa pamięci lokalnej do utrwalenia sesji, jeśli użytkownik jest w trybie przeglądania prywatnego, zgłasza „QuotaExceededError: DOM Exception 22: Podjęto próbę dodania do pamięci czegoś, co przekroczyło limit”. wyjątek i funkcje powodzenia / błędu nigdy nie są wywoływane.

W moim przypadku, ponieważ funkcja błędu nigdy nie jest wywoływana, początkowo wydawało się, że jest to problem z odpaleniem zdarzenia kliknięcia w przesłanym pliku lub przekierowaniem zdefiniowanym po pomyślnym zarejestrowaniu.

Dołączenie ostrzeżenia dla użytkowników rozwiązało problem.

Analiza składni SDK JavaScript https://parse.com/docs/js/api/classes/Parse.User.html#methods_signUp

Rejestruje nowego użytkownika za pomocą nazwy użytkownika (lub adresu e-mail) i hasła. Spowoduje to utworzenie nowego Parse.User na serwerze, a także utrwalenie sesji w localStorage , abyś mógł uzyskać dostęp do użytkownika za pomocą {@link #current}.