У меня есть мобильный веб-сайт, у которого есть div, прикрепленный к нижней части экрана через position: fixed. Все работает нормально в iOS 5 (тестирую на iPod Touch), пока я не нахожусь на странице с формой. Когда я нажимаю на поле ввода и появляется виртуальная клавиатура, внезапно фиксированная позиция моего div теряется. Теперь div прокручивает страницу, пока видна клавиатура. Когда я нажимаю «Готово», чтобы закрыть клавиатуру, div возвращается в свое положение в нижней части экрана и подчиняется правилу position: fixed.
Кто-нибудь еще испытывал подобное поведение? Ожидается ли это? Спасибо.
Ответы:
У меня была эта проблема в моем приложении. Вот как я работаю над этим:
Я просто прокручиваю вверх и размещаю его там, чтобы пользователь iOS не заметил ничего странного. Оберните это в некотором обнаружении пользовательского агента, чтобы другие пользователи не видели такого поведения.
источник
document.body.scrollTop = 0
если вы не используете jQuery и ориентируетесь на новейшие браузеры.$(window).scrollTop(0);
может привести к перемещению сфокусированного ввода за пределы экрана, например, ввод дальше вниз по странице или если iPhone находится в портретной ориентации. Лучшее решение - установить фокусheader.css({position:'absolute',top:window.pageYOffset+'px'});
и установить размытиеheader.css({position:'fixed',top:0});
.У меня была немного другая проблема с ipad, когда виртуальная клавиатура подтолкнула мое окно просмотра за пределы экрана. Затем, после того как пользователь закрыл виртуальную клавиатуру, мое окно просмотра все еще оставалось за кадром. В моем случае я сделал примерно следующее:
источник
Это код, который мы используем для решения проблемы с ipad. Он в основном обнаруживает несоответствия между смещением и положением прокрутки, что означает, что «фиксированный» работает неправильно.
источник
Элементы с фиксированным положением просто не обновляют свое положение, когда клавиатура поднята. Я обнаружил, что, обманывая Safari, заставляя думать, что размер страницы изменился, элементы меняют свое положение. Это не идеально, но, по крайней мере, вам не нужно беспокоиться о переключении на «положение: абсолютное» и отслеживании изменений самостоятельно.
Следующий код просто прослушивает, когда пользователь, вероятно, будет использовать клавиатуру (из-за того, что ввод сфокусирован), и пока он не услышит размытие, он просто прослушивает любые события прокрутки, а затем выполняет трюк с изменением размера. Кажется, до сих пор у меня все работает хорошо.
источник
На всякий случай, если кто-то наткнется на эту тему, как это сделал я, исследуя эту проблему. Я нашел эту ветку полезной в стимулировании моих размышлений по этому вопросу.
Это было моим решением в недавнем проекте. Вам просто нужно изменить значение targetElem на селектор jQuery, который представляет ваш заголовок.
Есть небольшая задержка с фиксацией исправления, потому что iOS останавливает манипуляции с DOM во время прокрутки, но это помогает ...
источник
init
функцию на обычную (не самозапускающуюся; срабатывает слишком рано). Тогда звонитеiOSKeyboardFix.init();
незадолго до окончанияif
заявления.Ни один из других ответов, которые я нашел для этой ошибки, не помог мне. Я смог исправить это, просто прокрутив страницу вверх на 34 пикселя, количество, которое мобильное сафари прокручивает вниз. с jquery:
Это, очевидно, будет действовать во всех браузерах, но предотвращает нарушение работы iOS.
источник
Эта проблема действительно раздражает.
Я объединил некоторые из вышеупомянутых техник и пришел к следующему:
У меня есть две фиксированные панели навигации (верхний и нижний колонтитулы, используя загрузку twitter). Оба вели себя странно, когда клавиатура поднята, и снова странно, когда клавиатура не работает.
С этим исправлением с задержкой / задержкой это работает. Время от времени я все еще нахожу сбой, но, похоже, он достаточно хорош, чтобы показать его клиенту.
Сообщите мне, работает ли это для вас. Если нет, мы можем найти что-нибудь еще. Спасибо.
источник
У меня была такая же проблема с iOS7. Нижние фиксированные элементы испортили бы мой взгляд, не сфокусировавшись должным образом.
Все заработало, когда я добавил этот метатег в свой html.
То, что имело значение, было:
Надеюсь, это кому-то поможет.
источник
Я взял
Jory Cunningham
ответ и улучшил его:Во многих случаях сходит с ума не один элемент, а несколько фиксированных позиционируемых элементов, поэтому в этом случае
targetElem
должен быть объект jQuery, который имеет все фиксированные элементы, которые вы хотите «исправить». Хо, похоже, клавиатура iOS исчезнет, если вы прокрутите ...Само собой разумеется, что вы должны использовать это событие ПОСЛЕ документа
DOM ready
или непосредственно перед закрывающим</body>
тегом.источник
У меня есть решение, похожее на @NealJMD, за исключением того, что мое выполняется только для iOS и правильно определяет смещение прокрутки, измеряя scollTop до и после прокрутки собственной клавиатуры, а также с помощью setTimeout, чтобы разрешить собственную прокрутку:
источник
Я исправил фиксированное положение содержимого основного макета Ipad следующим образом:
источник
setInterval
... действительно? лучше просто остаться с ошибкой, чем делать этоУ меня была аналогичная проблема с @ ds111 s. Клавиатура подтолкнула мой веб-сайт вверх, но не опустилась, когда клавиатура закрылась.
Сначала я попробовал решение @ ds111, но у меня было два
input
поля. Конечно, сначала уходит клавиатура, потом происходит размытие (или что-то в этом роде). Итак, второйinput
был под клавиатурой, когда фокус переключался напрямую с одного входа на другой.Кроме того, «прыжок вверх» для меня был недостаточно хорош, так как вся страница имеет размер только ipad. Поэтому я сделал прокрутку плавной.
Наконец, мне пришлось прикрепить прослушиватель событий ко всем входам, даже к тем, которые в данный момент были скрыты, поэтому
live
.Все вместе я могу объяснить следующий фрагмент javascript следующим образом: прикрепить следующий прослушиватель событий размытия к текущему и всем будущим
input
иtextarea
(=live
): подождать период отсрочки (=window.setTimeout(..., 10)
) и плавно прокрутить вверх (=animate({scrollTop: 0}, ...)
), но только если «нет клавиатуры показано "(=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) })
Имейте в виду, что период отсрочки (=
10
) может быть слишком коротким или клавиатура все еще отображается, хотя она отсутствуетinput
илиtextarea
находится в фокусе. Конечно, если вы хотите, чтобы прокрутка была быстрее или медленнее, вы можете настроить продолжительность (=400
)источник
действительно упорно трудился, чтобы найти этот обходной путь, который в короткие взгляды на фокус и размытия событий на входах и прокрутки, чтобы выборочно изменить позиционирование фиксированной панели, когда события происходят. Это пуленепробиваемое и охватывает все случаи (навигация с помощью <>, прокрутка, кнопка «Готово»). Обратите внимание: id = "nav" - это мой фиксированный div нижнего колонтитула. Вы можете легко перенести это на стандартный js или jquery. Это додзё для тех, кто пользуется электроинструментом ;-)
define (["dojo / ready", "dojo / query",], function (ready, query) {
}); // конец определения
источник
overflow:hidden
правило, вы вообще не увидите свой ввод, поскольку теперь он находится вне поля.Это сложная проблема, чтобы решить ее "правильно". Вы можете попробовать скрыть нижний колонтитул при фокусе элемента ввода и показать при размытии, но это не всегда надежно на iOS. Время от времени (один раз из десяти, скажем, на моем iPhone 4S) кажется, что событие focus не срабатывает (или, возможно, есть состояние гонки), и нижний колонтитул не скрывается.
После долгих проб и ошибок я пришел к следующему интересному решению:
По сути: используйте JavaScript для определения высоты окна устройства, затем динамически создайте медиа-запрос CSS, чтобы скрыть нижний колонтитул, когда высота окна уменьшается на 10 пикселей. Поскольку открытие клавиатуры изменяет размер дисплея браузера, это никогда не перестает работать на iOS. Поскольку он использует движок CSS, а не JavaScript, он также намного быстрее и плавнее!
Примечание. Я обнаружил, что использование «visibility: hidden» менее проблемно, чем «display: none» или «position: static», но ваш пробег может отличаться.
источник
Работает для меня
источник
В нашем случае это исправится само, как только пользователь прокрутит страницу. Итак, это исправление, которое мы использовали для имитации прокрутки
blur
на любомinput
илиtextarea
:источник
Мой ответ - это невозможно.
Я вижу 25 ответов, но в моем случае ни один из них не работает. Вот почему Yahoo и другие страницы скрывают фиксированный заголовок при включенной клавиатуре. И Bing делает всю страницу не прокручиваемой (overflow-y: hidden).
Обсуждаемые выше случаи разные, у некоторых есть проблемы с прокруткой, у некоторых с фокусом или размытием. У некоторых есть фиксированный нижний колонтитул или верхний колонтитул. Я не могу сейчас проверить каждую комбинацию, но вы можете в конечном итоге понять, что в вашем случае это невозможно.
источник
Нашел это решение на Github.
https://github.com/Simbul/baker/issues/504#issuecomment-12821392
Убедитесь, что у вас есть прокручиваемый контент.
Адресная строка складывается в виде дополнительного бонуса.
источник
На случай, если кто-то захочет попробовать это. Я получил следующую работу над фиксированным нижним колонтитулом с полем ввода в нем.
источник
У меня такая же проблема. Но я понял, что фиксированная позиция просто задерживается, а не нарушается (по крайней мере, для меня). Подождите 5-10 секунд и посмотрите, вернется ли div в нижнюю часть экрана. Я считаю, что это не ошибка, а задержка ответа при открытой клавиатуре.
источник
Я перепробовал все подходы из этой ветки, но если они не помогли, то стали еще хуже. В конце концов, я решил заставить устройство терять фокус:
и это сработало как шарм и исправило мою липкую форму входа.
Пожалуйста Примечание:
jQuery v1.10.2
источник
Это по-прежнему серьезная ошибка для любых HTML-страниц с более высокими модами Bootstrap в iOS 8.3. Ни одно из предложенных решений выше работали и после масштабирования на любом поле ниже складок высокого модальный, Mobile Safari и / или WkWebView будет двигаться неподвижными элементами , где прокручивать HTML тела располагались, оставляя их смещено с тем, где они на самом деле , где выложил.
Чтобы обойти ошибку, добавьте прослушиватель событий к любому из ваших модальных входов, например:
Я предполагаю, что это работает, потому что принуждение высоты прокрутки тела HTML повторно выравнивает фактическое представление с тем местом, где iOS 8 WebView ожидает фиксированного модального содержимого div.
источник
Если кто-то искал совершенно другой маршрут (например, вы даже не хотите закреплять этот div «нижний колонтитул» при прокрутке, но вы просто хотите, чтобы этот div оставался внизу страницы), вы можете просто установить положение нижнего колонтитула как родственник.
Это означает, что даже если виртуальная клавиатура появится в вашем мобильном браузере, нижний колонтитул останется привязанным к нижней части страницы, не пытаясь реагировать на показ виртуальной клавиатуры или закрытие.
Очевидно, что в Safari лучше выглядит, если положение фиксировано, а нижний колонтитул следует за страницей при прокрутке вверх или вниз, но из-за этой странной ошибки в Chrome мы в конечном итоге переключились на относительный нижний колонтитул.
источник
Ни одно из решений для прокрутки, похоже, не помогло мне. Вместо этого сработало то, что положение тела было зафиксировано, пока пользователь редактирует текст, а затем восстановлено статическое, когда пользователь закончит. Это удерживает сафари от прокрутки вашего контента на вас. Вы можете сделать это либо в фокусе / размытии элемента (ов) (показано ниже для одного элемента, но может быть для всего ввода, текстовых полей), либо если пользователь что-то делает, чтобы начать редактирование, например, открытие модального окна, вы можете сделать это действие (например, модальное открытие / закрытие).
источник
iOS9 - такая же проблема.
TL; DR - источник проблемы. Для решения прокрутите вниз
У меня была форма в
position:fixed
iframe с id = 'subscribe-popup-frame'Согласно исходному вопросу, при фокусе ввода iframe переместится в верхнюю часть документа, а не в верхнюю часть экрана.
Та же проблема не возникала в режиме safari dev с пользовательским агентом, установленным на idevice. Кажется, проблема вызвана виртуальной клавиатурой iOS, когда она появляется.
Я получил некоторое представление о том, что происходило, когда консоль регистрировала позицию iframe (например
$('#subscribe-popup-frame', window.parent.document).position()
), и оттуда я мог видеть, что iOS, похоже, устанавливает позицию элемента,{top: -x, left: 0}
когда виртуальная клавиатура появляется (т.е. фокусируется на элементе ввода).Итак, моим решением было принять это надоедливое
-x
, поменять знак и затем использовать jQuery, чтобы добавить этуtop
позицию обратно в iframe. Если есть лучшее решение, я хотел бы его услышать, но после того, как я испробовал десяток различных подходов, он оказался единственным, который у меня сработал.Недостаток: мне нужно было установить тайм-аут в 500 мс (возможно, сработало бы меньше, но я хотел быть в безопасности), чтобы убедиться, что я зафиксировал окончательное
x
значение после того, как iOS испортила положение элемента. В результате опыт очень отрывистый. . . но по крайней мере это работаетРешение
Тогда просто позвони
mobileInputReposition
что-нибудь вроде$('your-input-field).focus(function(){})
и$('your-input-field).blur(function(){})
источник