在做Web開發(fā)時(shí)，我們經(jīng)常用到頁(yè)面關(guān)閉事件onbeforeunload，可以給用戶一個(gè)選擇放棄關(guān)閉的機(jī)會(huì)，就比如這個(gè)博客編輯器。如果用戶選擇了離開，那么onunload事件自然會(huì)觸發(fā)；但若用戶選擇了取消，又該如何檢測(cè)呢？

我們假定一個(gè)頁(yè)面離開取消事件，叫做onunloadcancel。顯然，這個(gè)事件應(yīng)觸發(fā)在用戶按下對(duì)話框的取消按鈕之后。但關(guān)閉提示對(duì)話框的觸發(fā)流程并不是那么簡(jiǎn)單。我們先來(lái)回顧下這個(gè)過(guò)程：

當(dāng)用戶準(zhǔn)備離開頁(yè)面（比如按下關(guān)閉按鈕，或者刷新頁(yè)面等等），onbeforeunload事件觸發(fā)。我們的腳本無(wú)法在這個(gè)事件里決定是否阻止頁(yè)面的關(guān)閉，唯一能做到的只有返回一個(gè)字符串，這個(gè)字符串僅作為說(shuō)明文字出現(xiàn)在關(guān)閉選擇對(duì)話框里，用戶可以選擇關(guān)閉，或者不關(guān)閉。但究竟選擇哪個(gè)，我們無(wú)從得知。

然而仔細(xì)分析下這個(gè)問(wèn)題，其實(shí)不然。 如果用戶真選擇了關(guān)閉頁(yè)面，那么之后所有的運(yùn)行代碼都byebye了；而繼續(xù)留在頁(yè)面的話，就當(dāng)什么都沒(méi)發(fā)生過(guò)，除了onbeforeunload事件。所以，我們?cè)趏nbeforeunload事件里做點(diǎn)小花招，在此注冊(cè)個(gè)幾毫秒之后啟動(dòng)的定時(shí)器，如果頁(yè)面真關(guān)閉了，那么這個(gè)定時(shí)器當(dāng)然是作廢了；那么頁(yè)面還在，幾毫秒的延時(shí)對(duì)于這個(gè)本來(lái)就是異步的界面交互事件也沒(méi)有什么誤差。

有時(shí)按下關(guān)閉按鈕，也會(huì)執(zhí)行onunloadcancel，并且有個(gè)對(duì)話框一閃而過(guò)。如果換成while(1);瀏覽器會(huì)一直卡死，這說(shuō)明onunloadcancel確實(shí)是執(zhí)行了，只是銷毀了界面，但并沒(méi)有暫停腳本的運(yùn)行。
如果是通過(guò)刷新頁(yè)面的方式離開，僅執(zhí)行一次onbeforeunload，但點(diǎn)擊X按鈕關(guān)閉頁(yè)面，會(huì)執(zhí)行兩次onbeforeunload。因此我們還需在完善下，以便兼容FF。

最新評(píng)論