Saya memiliki situs web seluler yang memiliki div yang disematkan ke bagian bawah layar melalui posisi: tetap. Semua berfungsi dengan baik di iOS 5 (saya sedang menguji di iPod Touch) sampai saya berada di halaman dengan formulir. Saat saya masuk ke kolom input dan keyboard virtual muncul, tiba-tiba posisi div saya hilang. Div sekarang menggulir dengan halaman selama keyboard terlihat. Setelah saya mengklik Selesai untuk menutup keyboard, div kembali ke posisinya di bagian bawah layar dan mematuhi aturan posisi: tetap.
Apakah ada orang lain yang pernah mengalami perilaku seperti ini? Apakah ini diharapkan? Terima kasih.
Jawaban:
Saya memiliki masalah ini dalam aplikasi saya. Inilah cara saya mengatasinya:
Saya hanya menggulir ke atas dan memposisikannya di sana, sehingga pengguna iOS tidak melihat sesuatu yang aneh sedang terjadi. Gabungkan ini dalam beberapa deteksi agen pengguna sehingga pengguna lain tidak mendapatkan perilaku ini.
sumber
document.body.scrollTop = 0
jika Anda tidak menggunakan jQuery dan menargetkan browser terbaru.$(window).scrollTop(0);
dapat menyebabkan input yang difokuskan dipindahkan dari layar misalnya input lebih jauh ke bawah halaman, atau jika iPhone dalam potret. Solusi yang lebih baik adalah pada set fokusheader.css({position:'absolute',top:window.pageYOffset+'px'});
dan pada set blurheader.css({position:'fixed',top:0});
.Saya memiliki masalah ipad yang sedikit berbeda di mana keyboard virtual mendorong viewport saya ke atas dari layar. Kemudian setelah pengguna menutup keyboard virtual, viewport saya masih di luar layar. Dalam kasus saya, saya melakukan sesuatu seperti berikut:
sumber
Ini adalah kode yang kami gunakan untuk memperbaiki masalah dengan ipad. Ini pada dasarnya mendeteksi perbedaan antara offset dan posisi gulir - yang berarti 'tetap' tidak berfungsi dengan benar.
sumber
Elemen posisi tetap tidak memperbarui posisinya saat keyboard naik. Saya menemukan bahwa dengan mengelabui Safari dengan berpikir bahwa halaman telah diubah ukurannya, elemen akan memposisikan ulang dirinya sendiri. Ini tidak sempurna, tetapi setidaknya Anda tidak perlu khawatir tentang beralih ke 'posisi: mutlak' dan melacak perubahan sendiri.
Kode berikut hanya mendengarkan kapan pengguna kemungkinan besar akan menggunakan keyboard (karena input sedang difokuskan), dan sampai mendengar kabur itu hanya mendengarkan setiap kejadian gulir dan kemudian melakukan trik mengubah ukuran. Sepertinya bekerja cukup baik untuk saya sejauh ini.
sumber
Untuk berjaga-jaga jika seseorang terjadi pada utas ini seperti yang saya lakukan saat meneliti masalah ini. Saya menemukan utas ini membantu dalam merangsang pemikiran saya tentang masalah ini.
Ini adalah solusi saya untuk ini pada proyek terbaru. Anda hanya perlu mengubah nilai "targetElem" menjadi pemilih jQuery yang mewakili header Anda.
Ada sedikit penundaan dalam perbaikan berlangsung karena iOS menghentikan manipulasi DOM saat sedang bergulir, tetapi itu berhasil ...
sumber
init
menjadi fungsi biasa (tidak memanggil sendiri; ini diaktifkan terlalu dini). Kemudian panggiliOSKeyboardFix.init();
tepat sebelum akhirif
pernyataan.Tidak ada jawaban lain yang saya temukan untuk bug ini yang berhasil untuk saya. Saya dapat memperbaikinya hanya dengan menggulir halaman kembali ke atas sebesar 34px, jumlah safari seluler menggulirnya ke bawah. dengan jquery:
Ini jelas akan berlaku di semua browser, tetapi mencegahnya rusak di iOS.
sumber
Masalah ini sangat mengganggu.
Saya menggabungkan beberapa teknik yang disebutkan di atas dan menghasilkan ini:
Saya memiliki dua bilah navigasi tetap (header dan footer, menggunakan twitter bootstrap). Keduanya bertingkah aneh saat keyboard naik dan aneh lagi setelah keyboard turun.
Dengan perbaikan berwaktu / tertunda ini, ini berfungsi. Saya masih menemukan kesalahan sesekali, tetapi tampaknya cukup baik untuk menunjukkannya kepada klien.
Beri tahu saya jika ini berhasil untuk Anda. Jika tidak, kami mungkin dapat menemukan yang lain. Terima kasih.
sumber
Saya mengalami masalah yang sama dengan iOS7. Elemen tetap bawah akan mengacaukan pandangan saya yang tidak fokus dengan benar.
Semua mulai bekerja ketika saya menambahkan tag meta ini ke html saya.
Bagian yang membuat perbedaan adalah:
Harapan yang membantu seseorang.
sumber
Saya sudah mengambil
Jory Cunningham
jawaban dan memperbaikinya:Dalam banyak kasus, bukan hanya satu elemen yang menjadi gila, tetapi beberapa elemen yang diposisikan tetap, jadi dalam kasus ini,
targetElem
harus berupa objek jQuery yang memiliki semua elemen tetap yang ingin Anda "perbaiki". Ho, ini sepertinya membuat keyboard iOS hilang jika Anda menggulir ...Perlu disebutkan, Anda harus menggunakan acara dokumen SETELAH
DOM ready
ini atau tepat sebelum</body>
tag penutup .sumber
Saya memiliki solusi yang mirip dengan @NealJMD kecuali milik saya hanya mengeksekusi untuk iOS dan benar menentukan offset gulir dengan mengukur scollTop sebelum dan sesudah pengguliran keyboard asli serta menggunakan setTimeout untuk memungkinkan pengguliran asli terjadi:
sumber
Saya telah memperbaiki posisi tetap konten tata letak utama Ipad saya dengan cara ini:
sumber
setInterval
... Betulkah? lebih baik tetap bersama bug daripada melakukan iniSaya memiliki masalah yang mirip dengan @ ds111 s. Situs web saya didorong ke atas oleh keyboard tetapi tidak bergerak ke bawah saat keyboard ditutup.
Pertama saya mencoba solusi @ ds111 tetapi saya memiliki dua
input
bidang. Tentu saja, pertama-tama keyboard hilang, kemudian keburaman terjadi (atau semacamnya). Jadi yang keduainput
berada di bawah keyboard, ketika fokus dialihkan langsung dari satu input ke input lainnya.Selain itu, "jump up" tidak cukup baik untuk saya karena seluruh halaman hanya seukuran ipad. Jadi saya membuat gulungan itu mulus.
Akhirnya, saya harus melampirkan event listener ke semua input, bahkan yang saat ini tersembunyi, karenanya
live
.Secara keseluruhan saya dapat menjelaskan cuplikan javascript berikut sebagai: Lampirkan pemroses acara blur berikut ke saat ini dan semua yang akan datang
input
dantextarea
(=live
): Tunggu masa tenggang (=window.setTimeout(..., 10)
) dan gulir dengan lancar ke atas (=animate({scrollTop: 0}, ...)
) tetapi hanya jika "tidak ada keyboard ditampilkan "(=if($('input:focus, textarea:focus').length == 0)
).$('input, textarea').live('blur', function(event) { window.setTimeout(function() { if($('input:focus, textarea:focus').length == 0) { $("html, body").animate({ scrollTop: 0 }, 400); } }, 10) })
Ketahuilah, bahwa masa tenggang (=
10
) mungkin terlalu pendek atau keyboard mungkin masih ditampilkan meskipun tidak adainput
atautextarea
sedang dalam fokus. Tentu saja, jika Anda ingin scrolling lebih cepat atau lebih lambat, Anda dapat menyesuaikan durasi (=400
)sumber
benar-benar bekerja keras untuk menemukan solusi ini, yang singkatnya mencari fokus dan mengaburkan peristiwa pada masukan, dan menggulir untuk secara selektif mengubah posisi bilah tetap saat peristiwa terjadi. Ini antipeluru, dan mencakup semua kasus (menavigasi dengan <>, gulir, tombol selesai). Catatan id = "nav" adalah div footer tetap saya. Anda dapat dengan mudah mem-port ini ke js standar, atau jquery. Ini adalah dojo bagi mereka yang menggunakan perkakas listrik ;-)
definisikan (["dojo / siap", "dojo / kueri",], fungsi (siap, kueri) {
}); // akhir mendefinisikan
sumber
overflow:hidden
aturan, Anda tidak akan melihat masukan Anda sama sekali karena sekarang berada di luar kotak.Ini adalah masalah yang sulit untuk mendapatkan jawaban yang 'benar'. Anda dapat mencoba dan menyembunyikan footer pada fokus elemen input, dan menampilkan blur, tetapi itu tidak selalu dapat diandalkan di iOS. Seringkali (satu dari sepuluh, katakanlah, pada iPhone 4S saya) acara fokus sepertinya gagal menyala (atau mungkin ada kondisi balapan), dan footer tidak disembunyikan.
Setelah banyak trial and error, saya menemukan solusi menarik ini:
Intinya: gunakan JavaScript untuk menentukan tinggi jendela perangkat, lalu buat kueri media CSS secara dinamis untuk menyembunyikan footer saat tinggi jendela menyusut 10 piksel. Karena membuka keyboard mengubah ukuran tampilan browser, ini tidak pernah gagal di iOS. Karena menggunakan mesin CSS daripada JavaScript, ini jauh lebih cepat dan lebih lancar juga!
Catatan: Saya menemukan menggunakan 'visibility: hidden' less glitchy than 'display: none' atau 'position: static', tetapi jarak tempuh Anda mungkin berbeda.
sumber
Bekerja untuk saya
sumber
Dalam kasus kami, ini akan memperbaiki dirinya sendiri segera setelah pengguna menggulir. Jadi ini adalah perbaikan yang kami gunakan untuk mensimulasikan gulir
blur
pada salah satuinput
atautextarea
:sumber
Jawaban saya adalah tidak bisa dilakukan.
Saya melihat 25 jawaban tetapi tidak ada yang berhasil dalam kasus saya. Itulah mengapa Yahoo dan halaman lain menyembunyikan header tetap saat keyboard aktif. Dan Bing mengubah seluruh halaman menjadi non-scrollable (overflow-y: hidden).
Kasus yang dibahas di atas berbeda, beberapa memiliki masalah saat menggulir, beberapa di fokus atau kabur. Beberapa memiliki footer tetap, atau header. Saya tidak dapat menguji setiap kombinasi sekarang, tetapi Anda mungkin akhirnya menyadari bahwa itu tidak dapat dilakukan dalam kasus Anda.
sumber
Temukan solusi ini di Github.
https://github.com/Simbul/baker/issues/504#issuecomment-12821392
Pastikan Anda memiliki konten yang dapat digulir.
Bilah alamat dilipat sebagai bonus tambahan.
sumber
Seandainya ada yang ingin mencoba ini. Saya mendapatkan yang berikut ini untuk saya di footer tetap dengan inputfield di dalamnya.
sumber
Saya memiliki masalah yang sama. Tetapi saya menyadari bahwa posisi tetap hanya tertunda dan tidak rusak (setidaknya untuk saya). Tunggu 5-10 detik dan lihat apakah div menyesuaikan kembali ke bagian bawah layar. Saya yakin ini bukan kesalahan, tetapi respons yang tertunda saat keyboard terbuka.
sumber
Saya mencoba semua pendekatan dari utas ini, tetapi jika tidak membantu, hasilnya malah lebih buruk. Pada akhirnya, saya memutuskan untuk memaksa perangkat kehilangan fokus:
dan itu bekerja seperti pesona dan memperbaiki formulir masuk lengket saya.
Harap CATATAN:
jQuery v1.10.2
sumber
Ini masih merupakan bug besar untuk setiap halaman HTML dengan Bootstrap Modals yang lebih tinggi di iOS 8.3. Tak satu pun dari solusi yang diusulkan di atas berfungsi dan setelah memperbesar bidang apa pun di bawah lipatan modal tinggi, Mobile Safari dan / atau WkWebView akan memindahkan elemen tetap ke tempat gulungan badan HTML berada, membiarkannya tidak sejajar dengan tempat sebenarnya. di mana ditata.
Untuk mengatasi bug tersebut, tambahkan event listener ke salah satu modal input Anda seperti:
Saya menduga ini berhasil karena memaksa tinggi gulir tubuh HTML menyelaraskan kembali tampilan sebenarnya dengan di mana iOS 8 WebView mengharapkan konten div modal tetap berada.
sumber
Jika ada yang mencari rute yang sama sekali berbeda (seperti Anda bahkan tidak ingin menyematkan div "footer" ini saat Anda menggulir tetapi Anda hanya ingin div tetap di bagian bawah halaman), Anda dapat mengatur posisi footer sebagai relatif.
Artinya, meskipun keyboard virtual muncul di browser seluler Anda, footer Anda akan tetap tertambat di bagian bawah halaman, tidak mencoba bereaksi terhadap tampilan atau penutupan keyboard virtual.
Jelas terlihat lebih baik di Safari jika posisinya diperbaiki dan footer mengikuti halaman saat Anda menggulir ke atas atau ke bawah tetapi karena bug aneh ini di Chrome, kami akhirnya beralih ke hanya membuat footer relatif.
sumber
Tidak ada solusi gulir yang tampaknya berhasil untuk saya. Alih-alih, yang berhasil adalah menyetel posisi badan menjadi tetap saat pengguna mengedit teks dan kemudian mengembalikannya ke statis saat pengguna selesai. Ini membuat safari tidak menggulir konten Anda pada Anda. Anda dapat melakukan ini baik pada fokus / blur elemen (ditampilkan di bawah untuk satu elemen tetapi bisa untuk semua input, textareas), atau jika pengguna melakukan sesuatu untuk mulai mengedit seperti membuka modal, Anda dapat melakukannya itu pada tindakan itu (misalnya buka / tutup modal).
sumber
iOS9 - masalah yang sama.
TLDR - sumber masalahnya. Untuk solusi, gulir ke bawah
Saya memiliki formulir dalam
position:fixed
iframe dengan id = 'subscribe-popup-frame'Sesuai pertanyaan awal, pada fokus input, iframe akan ditempatkan di bagian atas dokumen, bukan di bagian atas layar.
Masalah yang sama tidak terjadi dalam mode pengembang safari dengan agen pengguna disetel ke idevice. Jadi sepertinya masalahnya disebabkan oleh keyboard virtual iOS saat muncul.
Saya mendapat beberapa visibilitas tentang apa yang terjadi dengan konsol mencatat posisi iframe (misalnya
$('#subscribe-popup-frame', window.parent.document).position()
) dan dari sana saya dapat melihat iOS tampaknya mengatur posisi elemen ke{top: -x, left: 0}
saat keyboard virtual muncul (yaitu difokuskan pada elemen input).Jadi solusi saya adalah mengambil sial itu
-x
, membalikkan tandanya dan kemudian menggunakan jQuery untuk menambahkantop
posisi itu kembali ke iframe. Jika ada solusi yang lebih baik, saya akan senang mendengarnya tetapi setelah mencoba lusinan pendekatan berbeda, hanya itu yang berhasil untuk saya.Kekurangan: Saya perlu menetapkan batas waktu 500ms (mungkin lebih sedikit akan berfungsi tetapi saya ingin aman) untuk memastikan saya menangkap nilai akhir
x
setelah iOS melakukan kerusakannya dengan posisi elemen. Akibatnya, pengalaman itu sangat tersentak-sentak. . . tapi setidaknya itu berhasilLarutan
Kemudian panggil saja
mobileInputReposition
sesuatu seperti$('your-input-field).focus(function(){})
dan$('your-input-field).blur(function(){})
sumber