摘要：为什么安卓可以正常工作代码在刚运行的时候，就判断是否需要使用，我的安卓测试机大于且设置了。所以在安卓下我点击使用的原生事件当然没问题。在第二次手动事件中，因为此时为，所以在中返回，接着从而顺利触发了原生事件。
在昨天的一个移动端项目中引入fastclick后手动触发click事件失败，查看了文档也没有找到解决的办法，最后通过看fastclick源码才解决。
如果不想看中间这么多文字，可以直接翻到最后看结论。
想要实现的功能为点击div1的时候手动触发input的click事件。代码如下：
在没有引入fastclick的时候，可以按照预期工作，引入之后，在Android中也可以正常工作，但是在iOS却无论如何也不行。即使在input标签加上needsclick类也不行。
神奇的是如果连续手动触发两次click事件，则在iOS中就可以正常工作了！！
代码如下：
handleClick() {
this.$refs.input.click()
this.$refs.input.click()
}
想来想去，原因只能出在fastclick身上，首先看了文档，并没有发现解决的方法，只能去看源码了。虽然第一次用fastclick的时候就读过代码，当时只不过为了知道大概实现原理泛泛的读了一遍，不够细致。这次又重新看了一遍。关于源码的解读网上有很多，这里就不细说，代码不长，建议最好自己读一读。
追踪溯源，找到问题原因症结看完源码，就可以回答之前的疑问了。
代码：
if (deviceIsAndroid) {
metaViewport = document.querySelector("meta[name=viewport]");
if (metaViewport) {
// Chrome on Android with user-scalable="no" doesn"t need FastClick (issue #89)
if (metaViewport.content.indexOf("user-scalable=no") !== -1) {
return true;
}
// Chrome 32 and above with width=device-width or less don"t need FastClick
if (chromeVersion > 31 && document.documentElement.scrollWidth <= window.outerWidth) {
return true;
}
}
// Chrome desktop doesn"t need FastClick (issue #15)
} else {
return true;
}
在fastclick刚运行的时候，就判断是否需要使用fastclick，我的安卓测试机chrome大于32 且设置了width=device-width。所以在安卓下我点击使用的原生click事件当然没问题。
这就是这次“事故”的关键所在，当我点击的时候，一共触发了单词click事件，其中第一次为点击div触发，后两次为手动触发input的click事件。
第一次click事件时，fastclick在onTouchStart中将targetElement设置为div1,
这次成功执行sendClick() ，目标并不是我们想要的input。
紧接着是第一次手动触发click事件，但是因为是通过element.click()函数手动触发，所以没有onTouchStart这个过程，因此此时targetElement当然还是div1 ！！！ 这时needsClick返回了false，从而导致onClick中onMouse函数也返回了false，并终止了事件，随后就将targetElement置为null。
在第二次手动click事件中，因为此时targetElement为null，所以在onMouse中返回true，接着从而顺利触发了原生click事件。
if (!this.targetElement) {
return true;
}
因为第一次手动执行click() 的时，这时候的targetElement还是div1，即点击时的元素，而我将needsclick绑定在input上了，因此当然在targetElement上找不到needsclick了。
此时我们也就找到了解决问题的办法：将needsclick绑定在div1，即实际点击的元素上。
如果想触发原生click事件，请将needsclick绑定在实际点击的元素上，即e.targe上，而不是你手动触发的元素上。这可以说是fastclick的一个小bug，因为之前的点击影响了后面的点击。
只能在click的回调函数中手动触发element.click() ，否则无效，有兴趣的可以试试。这个在MDN上没写，算是意外收获。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/82764.html
摘要：但这样副作用也很大，移动端的交互体验全靠触摸，将会干扰其他交互行为的处理，例如滚动拖拽等。方案模拟修复法既然浏览器有这的延迟，那么我们来代替浏览器判断，手动触发事件，这也是的解决方案。 众所周知，移动端在处理点击事件的时候，会有300毫秒的延迟。恰恰是这300毫秒的延迟，会让人有一种卡顿的体验。 这300毫秒的原因，在于早期浏览器的实现中，浏览器不知道用户触摸后，到底想做什么，所以故意...
摘要：移动端触摸点击事件优化源码学习最近在做一些微信移动端的页面，在此记录关于移动端触摸和点击事件的学习优化过程，主要内容围绕展开。当指针设备通常指鼠标在元素上移动时事件被触发。移动端有延迟问题，可没有哦。 移动端触摸、点击事件优化（fastclick源码学习） 最近在做一些微信移动端的页面，在此记录关于移动端触摸和点击事件的学习优化过程，主要内容围绕fastclick展开。fastclic...
摘要：移动端触摸点击事件优化源码学习最近在做一些微信移动端的页面，在此记录关于移动端触摸和点击事件的学习优化过程，主要内容围绕展开。当指针设备通常指鼠标在元素上移动时事件被触发。移动端有延迟问题，可没有哦。 移动端触摸、点击事件优化（fastclick源码学习） 最近在做一些微信移动端的页面，在此记录关于移动端触摸和点击事件的学习优化过程，主要内容围绕fastclick展开。fastclic...
摘要：浏览器自动响应后续处理。浏览器行为部分是猜测，未验证。至于解决方案网上有很多，目前最好的是，不过也会有其他问题，例如在滑动中点击之类的。 问题来源 年前去阿里面试，过程中说道了fastclick解决iPhone机器上300ms点击延迟的问题，然后就被问到了zepto的点击穿透的现象以及产生这个具体原因，当时回答的不是很好，主要是没有特别深入的去研究这个原因，只是知道有这个现象和问题，大...
阅读 3627·2021-08-11 11:16
阅读 1477·2019-08-30 15:44
阅读 1900·2019-08-29 18:45
阅读 2121·2019-08-26 18:18
阅读 815·2019-08-26 13:37
阅读 1448·2019-08-26 11:43
阅读 1981·2019-08-26 11:34
阅读 264·2019-08-26 10:59
