資訊專欄INFORMATION COLUMN
摘要：為什么安卓可以正常工作代碼在剛運行的時候，就判斷是否需要使用，我的安卓測試機大于且設置了。所以在安卓下我點擊使用的原生事件當然沒問題。在第二次手動事件中，因為此時為，所以在中返回，接著從而順利觸發(fā)了原生事件。
在昨天的一個移動端項目中引入fastclick后手動觸發(fā)click事件失敗，查看了文檔也沒有找到解決的辦法，最后通過看fastclick源碼才解決。
如果不想看中間這么多文字，可以直接翻到最后看結論。
想要實現(xiàn)的功能為點擊div1的時候手動觸發(fā)input的click事件。代碼如下：
在沒有引入fastclick的時候，可以按照預期工作，引入之后，在Android中也可以正常工作，但是在iOS卻無論如何也不行。即使在input標簽加上needsclick類也不行。
神奇的是如果連續(xù)手動觸發(fā)兩次click事件，則在iOS中就可以正常工作了??！
代碼如下：
handleClick() {
this.$refs.input.click()
this.$refs.input.click()
}
想來想去，原因只能出在fastclick身上，首先看了文檔，并沒有發(fā)現(xiàn)解決的方法，只能去看源碼了。雖然第一次用fastclick的時候就讀過代碼，當時只不過為了知道大概實現(xiàn)原理泛泛的讀了一遍，不夠細致。這次又重新看了一遍。關于源碼的解讀網(wǎng)上有很多，這里就不細說，代碼不長，建議最好自己讀一讀。
追蹤溯源，找到問題原因癥結看完源碼，就可以回答之前的疑問了。
代碼：
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事件當然沒問題。
這就是這次“事故”的關鍵所在，當我點擊的時候，一共觸發(fā)了單詞click事件，其中第一次為點擊div觸發(fā)，后兩次為手動觸發(fā)input的click事件。
第一次click事件時，fastclick在onTouchStart中將targetElement設置為div1,
這次成功執(zhí)行sendClick() ，目標并不是我們想要的input。
緊接著是第一次手動觸發(fā)click事件，但是因為是通過element.click()函數(shù)手動觸發(fā)，所以沒有onTouchStart這個過程，因此此時targetElement當然還是div1 ！?。?這時needsClick返回了false，從而導致onClick中onMouse函數(shù)也返回了false，并終止了事件，隨后就將targetElement置為null。
在第二次手動click事件中，因為此時targetElement為null，所以在onMouse中返回true，接著從而順利觸發(fā)了原生click事件。
if (!this.targetElement) {
return true;
}
因為第一次手動執(zhí)行click() 的時，這時候的targetElement還是div1，即點擊時的元素，而我將needsclick綁定在input上了，因此當然在targetElement上找不到needsclick了。
此時我們也就找到了解決問題的辦法：將needsclick綁定在div1，即實際點擊的元素上。
如果想觸發(fā)原生click事件，請將needsclick綁定在實際點擊的元素上，即e.targe上，而不是你手動觸發(fā)的元素上。這可以說是fastclick的一個小bug，因為之前的點擊影響了后面的點擊。
只能在click的回調函數(shù)中手動觸發(fā)element.click() ，否則無效，有興趣的可以試試。這個在MDN上沒寫，算是意外收獲。
文章版權歸作者所有，未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉載請注明本文地址：http://systransis.cn/yun/82764.html
摘要：但這樣副作用也很大，移動端的交互體驗全靠觸摸，將會干擾其他交互行為的處理，例如滾動拖拽等。方案模擬修復法既然瀏覽器有這的延遲，那么我們來代替瀏覽器判斷，手動觸發(fā)事件，這也是的解決方案。 眾所周知，移動端在處理點擊事件的時候，會有300毫秒的延遲。恰恰是這300毫秒的延遲，會讓人有一種卡頓的體驗。 這300毫秒的原因，在于早期瀏覽器的實現(xiàn)中，瀏覽器不知道用戶觸摸后，到底想做什么，所以故意...
摘要：移動端觸摸點擊事件優(yōu)化源碼學習最近在做一些微信移動端的頁面，在此記錄關于移動端觸摸和點擊事件的學習優(yōu)化過程，主要內容圍繞展開。當指針設備通常指鼠標在元素上移動時事件被觸發(fā)。移動端有延遲問題，可沒有哦。 移動端觸摸、點擊事件優(yōu)化（fastclick源碼學習） 最近在做一些微信移動端的頁面，在此記錄關于移動端觸摸和點擊事件的學習優(yōu)化過程，主要內容圍繞fastclick展開。fastclic...
摘要：移動端觸摸點擊事件優(yōu)化源碼學習最近在做一些微信移動端的頁面，在此記錄關于移動端觸摸和點擊事件的學習優(yōu)化過程，主要內容圍繞展開。當指針設備通常指鼠標在元素上移動時事件被觸發(fā)。移動端有延遲問題，可沒有哦。 移動端觸摸、點擊事件優(yōu)化（fastclick源碼學習） 最近在做一些微信移動端的頁面，在此記錄關于移動端觸摸和點擊事件的學習優(yōu)化過程，主要內容圍繞fastclick展開。fastclic...
摘要：瀏覽器自動響應后續(xù)處理。瀏覽器行為部分是猜測，未驗證。至于解決方案網(wǎng)上有很多，目前最好的是，不過也會有其他問題，例如在滑動中點擊之類的。 問題來源 年前去阿里面試，過程中說道了fastclick解決iPhone機器上300ms點擊延遲的問題，然后就被問到了zepto的點擊穿透的現(xiàn)象以及產(chǎn)生這個具體原因，當時回答的不是很好，主要是沒有特別深入的去研究這個原因，只是知道有這個現(xiàn)象和問題，大...
閱讀 3758·2021-08-11 11:16
閱讀 1629·2019-08-30 15:44
閱讀 1998·2019-08-29 18:45
閱讀 2279·2019-08-26 18:18
閱讀 1010·2019-08-26 13:37
閱讀 1576·2019-08-26 11:43
閱讀 2125·2019-08-26 11:34
閱讀 380·2019-08-26 10:59
