iOS 7 Safari:单击/聚焦 HTML 输入时,操作系统会锁定 4 秒 [英] iOS 7 Safari: OS locks up for 4 seconds when clicking/focusing on a HTML input

查看:10
本文介绍了iOS 7 Safari:单击/聚焦 HTML 输入时,操作系统会锁定 4 秒的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

更新:问题似乎源于页面上有许多选择元素.这有多随机?

问题来了.在 iOS 7 Safari 上,当点击我网站上的文本输入时,键盘打开然后冻结操作系统大约 2-5 秒,然后最终滚动到输入.这种情况发生一次后,它就不会再发生,直到您刷新页面.我已经查看了所有地方,是的,iOS 7 Safari 有很多问题,但让我们尝试看看我们是否能解决这个问题.

So here's the issue. On iOS 7 Safari, when tapping the a text input on my site, the keyboard opens then freezes the OS for about 2-5 seconds then finally scrolls to the input. After this happens once, it never happens again until you refresh the page. I've looked all over the place, and yes, iOS 7 Safari is super buggy, but lets try and see if we can figure this out.

注意:这不会在任何其他移动浏览器或任何以前的 iOS Safari 中发生.它发生在 ios 7 iphone 和 ios 7 ipad 上.

Note: This does not happen in any other mobile browser or any previous iOS Safari. It happens both on the ios 7 iphone and ios 7 ipad.

我会列出我的朋友和我迄今为止尝试过的所有内容:

I will list everything my friend and I have tried so far:

  • 移除了在 jQuery 中添加事件处理程序的功能.(注意:我们所有的事件处理程序都是通过 jQuery 分配的,除了 unload 和 onpageshow).
  • 从输入中删除了 jQuery 自动完成脚本.
  • 从输入中删除了所有 JavaScript.
  • 通过拒绝 Mac 上的域删除了页面上添加的所有第三方库.
  • 切换回以前的 jQuery 版本.在没有任何效果之前,我们实际上可以使用的最后一个是 1.7.0.
  • 切换回以前的 jQuery UI 版本.
  • 将输入事件处理更改为委托和实时处理,而不是 on('click')
  • 删除了所有 CSS 类.
  • 从页面中删除了所有 CSS.注意:操作系统的响应时间减少到 1-2 秒,但仍然发生.

有人有什么想法吗?

非常感谢!

推荐答案

(有一些比较有效的解决方案,见列表末尾)

(There are some somewhat-effective solutions, see near the end of the list)

在我的公司,我们也遇到了这种情况.我们向 Apple 提出了问题,但听到了妈妈的声音.

At my company we are also suffering from this. We filed an issue with Apple but have heard mum.

这里有一些有趣的 jsfiddles 来帮助说明一些问题,它似乎肯定围绕着隐藏字段的数量,而 textareas 似乎没有受到影响.

Here are some interesting jsfiddles to help illustrate some of the issues, it definitely seems to revolve around the number of hidden fields, and textareas do not seem to be affected.

从调试工作来看,我的猜测是有一些功能试图检测输入是信用卡或电话号码还是某种似乎导致锁定行为的特殊类型.不过这只是一种假设..

From debugging efforts, my guess is that there is some functionality trying to detect if an input is a credit card or phone number or some special kind which seems to cause the locking behavior. This is just one hypothesis though..

总结:

在容器内包含命名输入元素且标记为display: none"的表单的页面上,第一次按下该表单中的输入时,在键盘出现和输入被集中.这会阻止用户使用我们的网络应用程序,因为用户界面冻结等待键盘响应花费了大量时间.我们已经在各种场景中对其进行了调试,以尝试辨别发生了什么,这似乎是由于 iOS7 解析 DOM 的方式与在 iOS6 上的方式发生了变化,后者没有这些问题.

On a page with a form containing named input elements inside containers that are marked "display: none", the first press on an input in that form has a very noticeable delay (20sec-2min) between the keyboard coming up and the input being focused. This prevents users from using our web app due to the enormous time spent with the ui frozen waiting for the keyboard to respond. We have debugged it in various scenarios to try and discern what is going on, and it appears to be from a change in how iOS7 parses the DOM versus how it did on iOS6, which has none of these issues.

在连接 iPad 的 Safari Inspector 中进行调试时,我们发现 iOS7 提供了更多有关(程序)活动的信息,以至于我们发现 _CollectFormMetaData 是问题的根源.搜索元数据会导致大量流失,随着包含输入的隐藏容器数量的增加,这种流失超过线性增长.我们发现 _isVisible 和 _isRenderedFormElement 的调用次数远远超出了它们的合理性.此外,如果有帮助,我们发现一些与信用卡和地址簿相关的检测功能是大量时间消费者.

From debugging within Safari's Inspector with the iPad connected, we found that iOS7 provides much more information about the (program)'s activities, to the point that we found that _CollectFormMetaData is the parent of the problem. Searching for meta data causes massive churn that increases more than linearly along with the number of hidden containers containing inputs. We found that _isVisible and _isRenderedFormElement are called far more than they reasonably should be. Additionally, if it helps, we found some detection functions relating to credit cards and address books were large time consumers.

这里有一些 jsFiddles 用于说明.请在运行 iOS6 的 iPad 上的 Safari 中查看它们,然后在运行 iOS7 的 iPad 上查看它们:

Here are some jsFiddles for illustration. Please view them in Safari on an iPad running iOS6 and then on an iPad running iOS7:

http://jsfiddle.net/gUDvL/20/ - 两者都运行良好

http://jsfiddle.net/gUDvL/21/ - 在 iOS 7 上有明显的延迟

http://jsfiddle.net/gUDvL/21/ - Just noticeable delay on iOS 7

http://jsfiddle.net/gUDvL/22/ - 在 iOS 7 上延迟更明显

http://jsfiddle.net/gUDvL/22/ - More noticeable delay on iOS 7

http://jsfiddle.net/gUDvL/29/ - iOS 7 上的延迟非常明显

http://jsfiddle.net/gUDvL/29/ - VERY noticeable delay on iOS 7

http://jsfiddle.net/gUDvL/30/ - 与 29 相同但没有隐藏 - 没有延迟iOS 7

http://jsfiddle.net/gUDvL/30/ - Same as 29 but with none hidden - no delay on iOS 7

http://jsfiddle.net/gUDvL/38/ - 与 29 相同但进一步恶化

http://jsfiddle.net/gUDvL/38/ - Same as 29 but further exacerbated

http://jsfiddle.net/gUDvL/39/ - 99 个隐藏输入,一个可见,一个单独可见

http://jsfiddle.net/gUDvL/39/ - 99 hidden inputs, one visible, one separately visible

http://jsfiddle.net/gUDvL/40/ - 99 个隐藏文本区域,一个可见,一个单独可见

http://jsfiddle.net/gUDvL/40/ - 99 hidden textareas, one visible, one separately visible

http://jsfiddle.net/gUDvL/41/ - 99 个隐藏输入,一个可见,一个单独可见,全部使用 autocomplete="off" 属性

http://jsfiddle.net/gUDvL/41/ - 99 hidden inputs, one visible, one separately visible, all with the autocomplete="off" attribute

http://jsfiddle.net/gUDvL/42/ - 99 个隐藏输入,一个可见,一个单独可见.按位置绝对和左侧隐藏而不是显示.

http://jsfiddle.net/gUDvL/42/ - 99 hidden inputs, one visible, one separately visible. Hidden by position absolute and left instead of display.

http://jsfiddle.net/gUDvL/63/ - 与 gUDvL/43/相同,但具有自动完成、自动更正、自动大写和拼写检查关闭

http://jsfiddle.net/gUDvL/63/ - Same as gUDvL/43/ but with autocomplete, autocorrect, autocapitalize, and spellcheck off

http://jsfiddle.net/gUDvL/65/ - 与 gUDvL/63/相同,但缩进已清理(在 iPad 上似乎更慢)

http://jsfiddle.net/gUDvL/65/ - Same as gUDvL/63/ but with cleaned up indentation (seems slower on iPad)

http://jsfiddle.net/gUDvL/66/ - 与 gUDvL/65/相同,但不显示通过css 再次代替 DOMReady jQuery

http://jsfiddle.net/gUDvL/66/ - Same as gUDvL/65/ but with display none via css again instead of DOMReady jQuery

http://jsfiddle.net/gUDvL/67/ - 与 gUDvL/66/相同,但具有 TedGrav 的重点/模糊技术

http://jsfiddle.net/gUDvL/67/ - Same as gUDvL/66/ but with TedGrav's focus/blur technique

http://jsfiddle.net/gUDvL/68/ - 与 gUDvL/66/相同,但使用 css 驱动的文本-缩进而不是显示:再次阻止(显着改进 - 初始焦点减少到 2-3 秒)

http://jsfiddle.net/gUDvL/68/ - Same as gUDvL/66/ but with css driven text-indent instead of display:block again (noticeable improvement - reduction to 2-3 secs for initial focus)

http://jsfiddle.net/gUDvL/69/ - 与 gUDvL/68/相同,但具有 TedGrav 的重点/模糊重新添加

http://jsfiddle.net/gUDvL/69/ - Same as gUDvL/68/ but with TedGrav's focus/blur re-added

http://jsfiddle.net/gUDvL/71/ - 与 gUDvL/66/相同,但 js 添加了一个每个输入之前的图例标签.(显着改进 - 初始专注时间减少到 2-3 秒)

http://jsfiddle.net/gUDvL/71/ - Same as gUDvL/66/ but with js adding a legend tag before each input. (noticeable improvement - reduction to 2-3 secs for initial focus)

<input type="text" autocomplete="off" /> (links to jsfiddle.net must be accompanied by code..)

(我们应该注意到,将 iPad 连接到 Mac 并使用 Safari 的调试器会极大地强调延迟.)

(We should note that having the iPad connected to a Mac with Safari's debugger engaged dramatically emphasizes the delays.)

重现步骤:

  1. 在 iPad 上加载任何上述 jsfiddles
  2. 按下输入以获得焦点
  3. 观看屏幕直到您可以输入

预期结果:

希望键盘一弹出就可以输入

Expect to be able to type as soon as the keyboard pops up

实际结果:

看着键盘弹出和屏幕冻结,在一段时间内无法滚动或与 Safari 交互.在持续时间之后,焦点按预期给出.从那时起,在专注于输入时不会再出现卡顿.

Watch the keyboard pop up and the screen freeze, unable to scroll or interact with Safari for a duration. After the duration, focus is given as expected. From then on no further freezes are experienced when focusing on inputs.

tl;dr 技术总结

所以总的来说,有几个来自各种答案的建议修复:

So overall there are a couple proposed fixes from various answers:

  • 不要用 display: none 隐藏 div - 使用类似 text-indent 的东西
  • 短路 Apple 的元数据扫描逻辑 - 许多表单标签或图例标签似乎都可以解决问题
  • 自动对焦/模糊 - 对我不起作用,但有两个人报告说它起作用了

Apple 的相关主题:

https://discussions.apple.com/thread/5468360

这篇关于iOS 7 Safari:单击/聚焦 HTML 输入时,操作系统会锁定 4 秒的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆