由 引起的思考

　　前陣子在一個移動項目中，經過 <a href = "#" >  的方式 綁定click 事件來提交一個表單，因爲表單信息比較敏感，因而採用的post 同步提交的方式，本來到也沒有什麼。後來萬惡的PM說 「你這個按鈕呀，要固定在底部比較好」 ，因而乎就經過 position:fixed 固定到底部了。那麼，問題來了 ， 在ios 下，虛擬鍵盤是浮在頁面上層的，致使的結果是當鍵盤收起後，浮在最底部的按鈕不在最底下，而跑到中間來了，(極端條件下還可能擋住輸入框致使沒法輸入)，而且隨着屏幕的滾動而滾動，，(表現相似於absolute) ，，高大上的蘋果也是真心坑了一回。

　　怎麼辦呢？ 兩種方案，一滾動時動態計算位置，實時監控位置一定是要消耗性能的，二是因爲沒法監控到虛擬鍵盤打開或者關閉，因此只能經過對錶單元素綁定focus和blur事件來改變按鈕position來達到想要的效果。因而balabala又搞完了。

　　搞完後就開始測試，而後有發現當有input元素處於focus狀態時，點擊提交按鈕，無效！！！我再點，好了。。。

　　緣由是由於blur事件會阻止click事件的執行。。。

　   好，我繼續改。

　　blur事件會阻止click事件的執行，可是不會阻止touch事件，因而想起把click改爲tap吧。還真行。不用再點擊兩次了。

　　大功告成，我得意的笑，我真聰明。

　　balabala 就上線了。

　　一上線發現提交不了了。。。有必定機率出現請求被canceled 。。。

             

各類google沒找出緣由，，問題出在哪裏？click是沒有問題，換成tap便有問題了，因而乎查了一下 touch event 的執行順序,大體是這樣

　　

因而我測試 mouseup 是好的，touchend也是有問題的，，tap也是有問題的，，而當我用tap事件，handler處理的時候延遲100ms再$('*Form').submit() 又能夠正常提交了。原來是submit執行的時機問題。

繼續各類debug 抓蟲子，，歷史遺留的坑啊，，

最終到 <a href = "#" > 了，，當按鈕點擊事件執行，在請求hash前執行submit , 請求還沒返回，因爲改變了hash，同步的submit被cancel了，，，而因爲各類緣由submit執行前，hash已經改變的話就能夠順利提交了，，

 

因而乎，把 <a href = "#" >  改爲 <a href = "javascript:void(0)" > 終於萬事大吉了。