Mam witrynę mobilną, w której u dołu ekranu jest przypięty element div za pomocą pozycji: fixed. Wszystko działa dobrze w iOS 5 (testuję na iPodzie Touch), dopóki nie wejdę na stronę z formularzem. Kiedy stukam w pole wprowadzania i pojawia się wirtualna klawiatura, nagle zostaje utracone ustalone położenie mojego elementu div. Element div przewija się teraz wraz ze stroną, o ile klawiatura jest widoczna. Po kliknięciu przycisku Gotowe, aby zamknąć klawiaturę, element div powraca do swojej pozycji u dołu ekranu i przestrzega zasady position: fixed.
Czy ktoś jeszcze doświadczył tego rodzaju zachowania? Czy jest to oczekiwane? Dzięki.
Odpowiedzi:
Miałem ten problem w swojej aplikacji. Oto jak nad tym pracuję:
Po prostu przewijam do góry i umieszczam go tam, aby użytkownik iOS nie zauważył, że dzieje się coś dziwnego. Uwzględnij to w wykrywaniu niektórych klientów użytkownika, aby inni użytkownicy nie odczuli tego zachowania.
źródło
document.body.scrollTop = 0
jeśli nie używasz jQuery i celujesz w najnowsze przeglądarki.$(window).scrollTop(0);
może spowodować przeniesienie skoncentrowanego wejścia poza ekran, np. Wejście dalej w dół strony lub jeśli iPhone jest ustawiony pionowo. Lepszym rozwiązaniem jest ustawienie ostrościheader.css({position:'absolute',top:window.pageYOffset+'px'});
i rozmycieheader.css({position:'fixed',top:0});
.Miałem nieco inny problem z iPadem, w którym klawiatura wirtualna wyrzuciła mój widoczny obszar poza ekran. Po tym, jak użytkownik zamknął wirtualną klawiaturę, mój widok był nadal poza ekranem. W moim przypadku zrobiłem coś takiego:
źródło
To jest kod, którego używamy do rozwiązywania problemów z iPadem. Zasadniczo wykrywa rozbieżności między przesunięciem a pozycją przewijania - co oznacza, że `` naprawiono '' nie działa poprawnie.
źródło
Elementy o ustalonej pozycji po prostu nie aktualizują swojej pozycji, gdy klawiatura jest podniesiona. Okazało się, że oszukując Safari, by pomyślał, że rozmiar strony zmienił się, elementy zmieniają swoje położenie. Nie jest idealne, ale przynajmniej nie musisz się martwić przełączeniem na „pozycję: absolutna” i samodzielnym śledzeniem zmian.
Poniższy kod po prostu nasłuchuje, kiedy użytkownik prawdopodobnie korzysta z klawiatury (z powodu koncentracji na danych wejściowych) i dopóki nie usłyszy rozmycia, po prostu nasłuchuje wszelkich zdarzeń przewijania, a następnie wykonuje sztuczkę ze zmianą rozmiaru. Jak dotąd wydaje mi się, że działa całkiem nieźle.
źródło
Na wypadek, gdyby ktoś trafił na ten wątek, tak jak ja, badając ten problem. Ten wątek okazał się pomocny w stymulowaniu mojego myślenia na ten temat.
To było moje rozwiązanie tego problemu w ostatnim projekcie. Wystarczy zmienić wartość „targetElem” na selektor jQuery, który reprezentuje twój nagłówek.
Jest trochę opóźnienie w utrzymywaniu poprawki, ponieważ iOS zatrzymuje manipulację DOM podczas przewijania, ale załatwia sprawę ...
źródło
init
na zwykłą funkcję (nie wywołuje się samoczynnie; uruchamia się za wcześnie). Następnie zadzwońiOSKeyboardFix.init();
tuż przed końcemif
instrukcji.Żadna z innych odpowiedzi na ten błąd, które znalazłem, nie zadziałała. Udało mi się to naprawić po prostu przewijając stronę z powrotem w górę o 34 piksele, ilość mobilnego safari przewija ją w dół. z jQuery:
To oczywiście zadziała we wszystkich przeglądarkach, ale zapobiega awariom w iOS.
źródło
Ten problem jest naprawdę irytujący.
Połączyłem niektóre z wyżej wymienionych technik i wymyśliłem to:
Mam dwa stałe paski nawigacyjne (nagłówek i stopka, używając programu ładującego Twitter). Obaj zachowywali się dziwnie, gdy klawiatura była podniesiona, i dziwnie znowu po jej wyłączeniu.
Z tą czasową / opóźnioną poprawką działa. Wciąż od czasu do czasu znajduję usterkę, ale wydaje się, że wystarczy, aby pokazać ją klientowi.
Daj mi znać, jeśli to zadziała. Jeśli nie, możemy znaleźć coś innego. Dzięki.
źródło
Miałem ten sam problem z iOS7. Dolne stałe elementy zepsułyby mój widok, który nie byłby prawidłowo ustawiony.
Wszystko zaczęło działać, kiedy dodałem ten metatag do mojego html.
Część, która spowodowała różnicę, to:
Mam nadzieję, że to komuś pomoże.
źródło
Wziąłem
Jory Cunningham
odpowiedź i poprawiłem ją:W wielu przypadkach szaleje nie tylko jeden element, ale kilka elementów o stałej pozycji, więc w tym przypadku
targetElem
powinien to być obiekt jQuery zawierający wszystkie ustalone elementy, które chcesz „naprawić”. Ho, wydaje się, że klawiatura iOS znika, jeśli przewijasz ...Nie trzeba wspominać, że powinieneś użyć tego zdarzenia PO dokumencie
DOM ready
lub tuż przed</body>
tagiem zamykającym .źródło
Mam rozwiązanie podobne do @NealJMD, z wyjątkiem tego, że moje wykonuje się tylko dla iOS i poprawnie określa przesunięcie przewijania, mierząc scollTop przed i po natywnym przewijaniu klawiatury, a także używając setTimeout, aby umożliwić przewijanie natywne:
źródło
Naprawiłem stałą pozycję zawartości głównego układu mojego iPada w ten sposób:
źródło
setInterval
... naprawdę? lepiej po prostu pozostać przy błędzie niż robić toMiałem podobny problem do @ ds111 s. Moja witryna została przesunięta w górę przez klawiaturę, ale nie przesunęła się w dół po zamknięciu klawiatury.
Najpierw wypróbowałem rozwiązanie @ ds111, ale miałem dwa
input
pola. Oczywiście najpierw klawiatura znika, potem następuje rozmycie (lub coś w tym rodzaju). A więc drugainput
był pod klawiaturą, kiedy fokus przełączał się bezpośrednio z jednego wejścia na drugie.Co więcej, „skok w górę” nie był dla mnie wystarczająco dobry, ponieważ cała strona ma tylko rozmiar iPada. Więc wygładziłem zwój.
Wreszcie musiałem dołączyć detektor zdarzeń do wszystkich wejść, nawet tych, które były obecnie ukryte, stąd plik
live
.Podsumowując, mogę wyjaśnić następujący fragment kodu javascript jako: Dołącz następujący detektor zdarzeń rozmycia do bieżącego i wszystkich przyszłych
input
oraztextarea
(=live
): Poczekaj okres karencji (=window.setTimeout(..., 10)
) i płynnie przewiń do góry (=animate({scrollTop: 0}, ...)
), ale tylko wtedy, gdy „nie ma klawiatury pokazano "(=if($('input:focus, textarea:focus').length == 0)
).Należy pamiętać, że okres karencji (=
10
) może być zbyt krótki lub klawiatura może być nadal wyświetlana, chociaż nie ma fokusainput
lubtextarea
jest fokus. Oczywiście, jeśli chcesz, aby przewijanie było szybsze lub wolniejsze, możesz dostosować czas trwania (=400
)źródło
Naprawdę ciężko pracowaliśmy, aby znaleźć to obejście, które w skrócie polega na wyszukiwaniu zdarzeń ostrości i rozmycia na danych wejściowych oraz przewijaniu w celu wybiórczej zmiany położenia stałego paska, gdy wystąpią zdarzenia. Jest to kuloodporne i obejmuje wszystkie przypadki (nawigacja za pomocą <>, przewijania, przycisku Gotowe). Note id = "nav" to mój element div w stałej stopce. Możesz łatwo przenieść to do standardowego js lub jquery. To dojo dla tych, którzy używają elektronarzędzi ;-)
define (["dojo / ready", "dojo / query",], function (ready, query) {
}); // koniec zdefiniuj
źródło
overflow:hidden
regułę, w ogóle nie zobaczysz wprowadzonych danych, ponieważ znajduje się poza polem.Jest to trudny problem do rozwiązania problemu. Możesz spróbować ukryć stopkę na fokusie elementu wejściowego i pokazać go przy rozmyciu, ale nie zawsze jest to niezawodne w systemie iOS. Co jakiś czas (powiedzmy raz na dziesięć na moim iPhonie 4S) zdarzenie ostrości wydaje się nie uruchamiać (lub może występuje stan wyścigu), a stopka nie jest ukryta.
Po wielu próbach i błędach wpadłem na to interesujące rozwiązanie:
Zasadniczo: użyj JavaScript, aby określić wysokość okna urządzenia, a następnie dynamicznie utwórz zapytanie CSS o media, aby ukryć stopkę, gdy wysokość okna zmniejszy się o 10 pikseli. Ponieważ otwarcie klawiatury zmienia rozmiar wyświetlacza przeglądarki, to nigdy nie kończy się niepowodzeniem w systemie iOS. Ponieważ używa silnika CSS zamiast JavaScript, jest też znacznie szybszy i płynniejszy!
Uwaga: znalazłem użycie opcji „widoczność: ukryta” mniej glitchy niż „wyświetlacz: brak” lub „pozycja: statyczna”, ale przebieg może się różnić.
źródło
Pracuje dla mnie
źródło
W naszym przypadku naprawiłoby się to, gdy tylko użytkownik przewija stronę. To jest poprawka, której używaliśmy do symulacji przewijania
blur
w dowolnyminput
lubtextarea
:źródło
Odpowiadam, że nie da się tego zrobić.
Widzę 25 odpowiedzi, ale żadna nie działa w moim przypadku. Dlatego Yahoo i inne strony ukrywają stały nagłówek, gdy klawiatura jest włączona. Bing zamienia całą stronę jako nieprzewijalną (overflow-y: hidden).
Omówione powyżej przypadki są różne, niektóre mają problemy z przewijaniem, inne z ostrością lub rozmyciem. Niektóre mają stałą stopkę lub nagłówek. Nie mogę teraz przetestować każdej kombinacji, ale możesz w końcu zdać sobie sprawę, że nie da się tego zrobić w twoim przypadku.
źródło
Znalazłem to rozwiązanie na Githubie.
https://github.com/Simbul/baker/issues/504#issuecomment-12821392
Upewnij się, że masz przewijalną zawartość.
Pasek adresu zwija się jako dodatkowy bonus.
źródło
Na wypadek, gdyby ktoś chciał tego spróbować. Mam następujący działający dla mnie na stałej stopce z polem wejściowym w nim.
źródło
Mam ten sam problem. Ale zdałem sobie sprawę, że stała pozycja jest po prostu opóźniona i nie jest zerwana (przynajmniej dla mnie). Poczekaj 5–10 sekund i zobacz, czy element DIV dostosuje się z powrotem do dołu ekranu. Uważam, że to nie błąd, ale opóźniona odpowiedź, gdy klawiatura jest otwarta.
źródło
Wypróbowałem wszystkie podejścia z tego wątku, ale jeśli nie pomogły, poszły jeszcze gorzej. Ostatecznie postanowiłem zmusić urządzenie do utraty ostrości:
i działało jak urok i naprawiło mój lepki formularz logowania.
Proszę UWAGA:
jQuery v1.10.2
źródło
Jest to nadal duży błąd dla wszystkich stron HTML z wyższymi modami Bootstrap w iOS 8.3. Żadne z proponowanych powyżej rozwiązań nie zadziałało i po powiększeniu dowolnego pola poniżej zagięcia wysokiego modalu, Mobile Safari i / lub WkWebView przesunie ustalone elementy do miejsca, w którym znajduje się przewijanie treści HTML, pozostawiając je nieprawidłowo wyrównane do miejsca, w którym faktycznie się znajdują rozłożone.
Aby obejść ten błąd, dodaj detektor zdarzeń do dowolnego z modalnych danych wejściowych, takich jak:
Domyślam się, że to działa, ponieważ wymuszenie wysokości przewijania treści HTML ponownie wyrównuje rzeczywisty widok z miejscem, w którym WebView systemu iOS 8 oczekuje, że będzie stała zawartość modalnego div.
źródło
Jeśli ktoś szukał zupełnie innej trasy (np. Nie chcesz nawet przypinać tego elementu div „footer” podczas przewijania, ale chcesz, aby element div pozostawał na dole strony), możesz po prostu ustawić położenie stopki jako krewny.
Oznacza to, że nawet jeśli klawiatura wirtualna pojawi się w przeglądarce mobilnej, stopka pozostanie zakotwiczona na dole strony, nie próbując reagować na pokaz wirtualnej klawiatury ani jej zamknąć.
Oczywiście w Safari wygląda lepiej, jeśli pozycja jest ustalona, a stopka podąża za stroną podczas przewijania w górę lub w dół, ale z powodu tego dziwnego błędu w przeglądarce Chrome przeszliśmy na względną stopkę.
źródło
Żadne z rozwiązań przewijania nie wydawało się działać dla mnie. Zamiast tego zadziałało ustawienie stałej pozycji ciała, gdy użytkownik edytuje tekst, a następnie przywrócenie go do statycznego, gdy użytkownik skończy. Dzięki temu Safari nie będzie przewijać Twoich treści. Możesz to zrobić albo skupiając się / rozmazując element (y) (pokazane poniżej dla pojedynczego elementu, ale może dotyczyć wszystkich danych wejściowych, obszarów tekstowych) lub jeśli użytkownik robi coś, aby rozpocząć edycję, np. Otwarcie okna modalnego, możesz to zrobić na tej akcji (np. modalne otwieranie / zamykanie).
źródło
iOS9 - ten sam problem.
TLDR - źródło problemu. Aby znaleźć rozwiązanie, przewiń do dołu
Miałem formularz w
position:fixed
ramce iframe z id = 'subscribe-popup-frame'Zgodnie z pierwotnym pytaniem, przy fokusie wejścia element iframe byłby na górze dokumentu, a nie na górze ekranu.
Ten sam problem nie wystąpił w trybie deweloperskim safari z agentem użytkownika ustawionym na idevice. Wygląda więc na to, że problem jest spowodowany przez wirtualną klawiaturę iOS, gdy się pojawia.
Uzyskałem pewien wgląd w to, co się dzieje, rejestrując przez konsolę pozycję elementu iframe (np.
$('#subscribe-popup-frame', window.parent.document).position()
) I stamtąd mogłem zobaczyć, jak iOS ustawia pozycję elementu,{top: -x, left: 0}
gdy pojawiła się wirtualna klawiatura (tj. Skupiła się na elemencie wejściowym).Więc moim rozwiązaniem było skorzystanie z tego nieznośnego
-x
, odwrócenie znaku, a następnie użycie jQuery, aby dodać tętop
pozycję z powrotem do iframe. Jeśli istnieje lepsze rozwiązanie, bardzo bym to usłyszał, ale po wypróbowaniu kilkunastu różnych podejść to jedyne, które mi się udało.Wada: musiałem ustawić limit czasu na 500 ms (może mniej by działało, ale chciałem być bezpieczny), aby upewnić się, że uchwyciłem ostateczną
x
wartość po tym, jak iOS zrobił psikusa z pozycją elementu. W rezultacie doświadczenie jest bardzo gwałtowne. . . ale przynajmniej działaRozwiązanie
Następnie zadzwoń
mobileInputReposition
na przykład$('your-input-field).focus(function(){})
i$('your-input-field).blur(function(){})
źródło