2014-06-26 19 views
5

Teraz jest to całkiem niezłe, więc domyślam się, że szukam wyjaśnienia, a nie poprawki (choć to byłby as), ale pamięć podręczna Wstecz/Przychodzące przeglądarki Safari jest przerażająco chciwa .Safari i jego chciwa, zachłanna pamięć podręczna

Mam problem polegający na tym, że formularz przesyła się, ale ładuje okno modalne pełnoekranowe przed przejściem do strony akcji formularza. W Safari pamięć podręczna jest tak silna, że ​​przycisk Wstecz ma otwarty tryb, co sprawia, że ​​moja dusza jest bardzo smutna.

Przełamuję go, odrzucając modal, a następnie przesyłając formularz. Z tyłu przeglądarka ma połowę zamkniętego modalu (to Bootstrap, więc zanika), który następnie po prostu odprawia.

Teraz wiem o onunload = "", ale odświeżanie strony wydaje się być szalone. Pamięć podręczna to dobra rzecz i coś, czego potrzebujesz, szczególnie w telefonach komórkowych.

Chyba moje pytanie brzmi:

dlaczego jest tak dużo bardziej intensywne niż powiedzieć Chrome i jest tam mimo wymuszania przeglądarki do pamięci podręcznej stan, a nie tylko ostatni stan?

Dzięki

+0

Czy nie można wyłączyć zanikania przed zwolnieniem modalu, a następnie ponownie włączyć po ponownym wyświetleniu strony? – CupawnTae

+0

Tak, to jest coś, co się dzieje. Istnieje kilka komplikacji dyrektywy AngularJS. – SpaceBeers

Odpowiedz

3

Hah, chciwy to mało powiedziane! Szczerze mówiąc, 99% czasu, projekt caching za Safari jest idealnym sposobem na obsługę przejść stron na urządzeniu mobilnym.

Kiedy idziesz od strony A do strony B, a następnie z powrotem do strony A, nie chcemy obciążać urządzenie (przepustowość, czas pracy baterii) z pobierania zasobów i aktywów, kiedy tylko może „wstrzymane” THE stan między interakcjami, a następnie "kontynuuj", gdy nawigujesz z powrotem.

To właśnie robi Safari Mobile. Używają koncepcji Page Cache, która utrzymuje całą stronę na żywo w pamięci, kiedy przechodzisz od jednego do drugiego. Zmniejsza to potrzebę pobierania tych zasobów i pozwala na szybką interakcję po kliknięciu.

To świetnie i wszystko ... ale to prowadzi do problemów (takich jak ten, który wychowałeś) - W szczególności, jak odróżnić stronę, która została zawieszona i która powinna zostać zniszczona?

Na szczęście, WebKit zapewnia zdarzenie pageshow i pagehide, które przechodzą w Page Cache. Oprócz wypalania, gdy strona jest wyświetlana lub ukrywana (podobna do onunload), ma świetną zdolność do wskazania, czy strona była persisted - lub umieszczona w pamięci podręcznej strony.

Chociaż nie jest to idealne rozwiązanie, można sprawdzić wydarzenie pageshow dla utrwalania, a następnie obsługiwać modal bardziej bezpośrednio (ponieważ wiesz, że był buforowany) tak, jakby natychmiast go ukrywał.

Jeśli tego nie zrobiłeś, spójrz na te dwa linki tutaj:

https://www.webkit.org/blog/427/webkit-page-cache-i-the-basics/ https://www.webkit.org/blog/516/webkit-page-cache-ii-the-unload-event/

Robią świetną robotę wyjaśniając Page Cache i obejmują próbki kodu zdarzenia pageshow i pagehide Nawiązałem wcześniej.

Mam nadzieję, że to pomoże!

+0

Naprawdę pomocne. Dzięki. Rozwiązałem mój problem, ale w paskudnym posiadłości. – SpaceBeers

Powiązane problemy