JS魔法堂:定義頁面的Dispose方法——[before]unload事件啓示錄

時間 2019-12-07

標籤定義頁面 dispose 方法 unload 事件啓示錄欄目 JavaScript 简体版

原文原文鏈接

前言

最近實施的同事報障，說用戶審批流程後直接關閉瀏覽器，操做十餘次後系統就報用戶會話數超過上限，諮詢4A同過後得知登錄後須要顯式調用登出API才能清理4A端，不然必然會超出會話上限。
即便在頁面上增添一個登出按鈕也沒法保證用戶不會直接關掉瀏覽器，更況且用戶已經習慣這樣作，增長功能好弄，改變習慣卻難啊。這時想起N年用過的window.onbeforeunload和window.onunload事件。
本文記錄重拾這兩個傢伙的通過，以便往後用時少坑。php

爲網頁寫個Dispose方法

C#中咱們會將釋放非託管資源等收尾工做放到Dispose方法中, 而後經過using語句塊自動調用該方法。對於網頁未嘗不是有大量收尾工做須要處理呢？那咱們是否也有相似的機制，讓程序變得更健壯呢？——那就靠beforeunload和unload事件了。但相對C#經過using語句塊自動調用Dispose方法，beforeunload和unload的觸發點則複雜很多。
咱們看看何時會觸發這兩個事件呢？html

在瀏覽器地址欄輸入地址，而後點擊跳轉；web
點擊頁面的連接實現跳轉；chrome
關閉或刷新當前頁面;瀏覽器
操做當前頁面的Location對象,修改當前頁面地址;緩存
調用window.navigate實現跳轉;網絡
調用window.open或document.open方法在當前頁面加載其餘頁面或從新打開輸入流。
OMG!這麼多操做會觸發這兩兄弟，怎麼處理纔好啊？沒啥辦法，針對功能需求作取捨咯。對於個人需求就是在頁面的Dispose方法中調用登出API，通過和實施同事的溝通——只要刷新頁面就觸發登出。dom

;(function(exports, $, url){
  exports.dispose = $.proxy($.get, $, url)
}(window, $, "http://pseudo.com/logout"))

那如今剩下的問題就在於究竟是在beforeunload仍是unload事件處理函數中調用dispose方法呢？這裏涉及兩點須要探討:ide

beforeunload和unload的功能定位是什麼？函數
beforeunload和unload的兼容性.

`beforeunload`和`unload`的功能定位是什麼？

beforeunload顧名思義就是在unload前觸發，可經過彈出二次確認對話框來試圖終斷執行unload.
unload就是正在進行頁面內容卸載時觸發的，通常在這裏進行一些重要的清理善後工做，而這時頁面處於如下一個特殊的臨時狀態:

頁面全部資源(img, iframe等)均未被釋放;
頁面可視區域一片空白;
UI人機交互失效(window.open,alert,confirm所有失效);
沒有任何操做能夠阻止unload過程的執行。(unload事件的Cancelable屬性值爲No)

那麼反過來看看beforeunload事件，這時頁面狀態大體與日常一致：

頁面全部資源均未釋放，且頁面可視區域效果沒有變化;
UI人機交互失效(window.open,alert,confirm所有失效);
最後時機能夠阻止unload過程的執行.(beforeunload事件的Cancelable屬性值爲Yes)

`beforeunload`和`unload`的兼容性

對於移動端瀏覽器而言(Safari, Opera Mobile等)而言不支持beforeunload事件,也許是由於移動端不建議干擾用戶操做流程吧。

防數據丟失機制——二次確認

當用戶正在編輯狀態時，若因誤操做離開頁面而致使數據丟失常做爲例外處理。處理方式大概有3種:

丟了就丟唄,而後就是誰用誰受罪了;
簡單粗暴——偵測處於編輯狀態時，監聽beforeunload事件做二次肯定,也就是將責任拋給用戶;
自動保存，甚至作到Work in Progress(參考john papa的分享John Papa-Progressive Savingr-NG-Conf)
這裏咱們選擇方式2，彈出二次肯定對話框。想到對話框天然會想到window.confirm，而後很天然地輸入如下代碼

window.addEventListener('beforeunload', function(e){
  var msg = "Do u want to leave?\nChanges u made may be lost."
  if (!window.confirm(msg)){
    e.preventDefault()
  }
})

而後刷新頁面發現啥都沒發生，接着直接蒙了。。。。。。

坑1: 無視`window.alert/confirm/prompt/showModalDialog`

beforeunload和unload是十分特殊的事件，要求事件處理函數內部不能阻塞當前線程，而window.alert/confirm/prompt/showModalDialog卻偏偏就會阻塞當前線程，所以H5規範中以明確在beforeunload和unload中直接無視這幾個方法的調用。

Since 25 May 2011, the HTML5 specification states that calls to window.showModalDialog(), window.alert(), window.confirm() and window.prompt() methods may be ignored during this event.(onbeforeunload#Notes)[https://developer.mozilla.org/en-US/docs/Web/API/WindowEventHandlers/onbeforeunload#Notes]

在chrome/chromium下會報"Blocked alert/prompt/confirm() during beforeunload/unload."的JS異常，而firefox下則連異常都懶得報。
既然不給用window.confirm,那麼如何彈出二次肯定對話框呢？其實beforeunload事件已經爲咱們準備好了。只要改爲

window.onbeforeunload = function(){
  var msg = "Do u want to leave?\nChanges u made may be lost."
  return msg
}

經過DOM0 Event Model的方式監聽beforeunload事件時，只需返回值不爲undefined或null，即會彈出二次肯定對話框。而IE和Chrome/Chromium則以返回值做爲對話框的提示信息，Firefox4開始會忽略返回值僅顯式內置的提示信息.
太不上道了吧，還在用DOM0 Event Model:( 那咱們來看看DOM2 Event Model是怎麼一個玩法

// Microsoft DOM2-ish Event Model
window.attachEvent('onbeforeunload', function(){
  var msg = "Do u want to leave?\nChanges u made may be lost."
  var evt = window.event
  evt.returnValue = msg
})

對於巨硬獨有的DOM2 Event Model，咱們經過設置window.event.returnValue爲非null或undefined來實現彈出窗的功能（注意：函數返回值是無效果的）
那麼標準的DOM2 Event Model呢？我記得window.event.returnValue是 for ie only的，但事件處理函數的返回值又木有效果，那隻能想到event.preventDefault()了,但event.preventDefault()沒有帶入參的重載，那麼是否意味經過標準DOM2 Event Model的方式就不支持自定義提示信息呢？

window.addEventListeners('beforeunload', function(e){
  e.preventDefault()
})

在FireFox上成功彈出對話框，但Chrome/Chromium上卻啥都沒發生。。。。。。

坑2: `HTMLElement.addEventListener`事件綁定

event.preventDefault()這一玩法就FireFox支持，Chrome此次站到IE的隊列上了。綜合起來的玩法是這樣的

;(function(exports){
  exports.genDispose = genDispose

  /**
   * @param {Function|String} [fnBody] - executed within the dispose method when it's data type is Function
   *                                     as return value of dispose method when it's data type is String
   * @param {String} [returnMsg]       - as return value of dispose method
   * @returns {Function}               - dispose method
   */
  function genDispose(fnBody, returnMsg){
    var args = getArgs(arguments)

    return function(e){
      args.fnBody && args.fnBody()
      if(e = e || window.event){
        args.returnMsg && e.preventDefault && e.preventDefault()
        e.returnValue = args.returnMsg
      }

      return args.returnMsg    
    }
  }

  function getArgs(args){
    var ret = {fnBody: void 0, returnMsg: args[1]},
        typeofArg0 = typeof args[0]

    if ("string" === typeofArg0){
      ret.returnMsg = args[0]
    }
    else if ("function" === typeofArg0){
      ret.fnBody = args[0]
    }

    retrn ret
  }

}(window))

// uses
var dispose = genDispose("Do u want to leave?\nChanges u made may be lost.")
window.onbeforeunload = dispose
window.attachEvent('onbeforeunload', dispose)
window.addEventListener('beforeunload', dispose)

坑3: 尊重用戶的選擇

有辦法阻止用戶關閉或刷新頁面嗎？沒辦法，二次肯定已是對用戶操做的最大限度的干擾了。

問題未解決——Cross-domain Redirection

;(function(exports){
  exports.Logout = Logout

  function Logout(url){
    if (this instanceof Logout);else return new Logout(url)
    this.url = url
  }
  Logout.prototype.exec = function(){
    var xhr = new XMLHttpRequest()
    xhr.open("GET", this.url, false)
    xhr.send()
  }
}(window))

var url = "http://pseudo.com/logout",
    logout = new Logout(url)
var dispose = $.proxy(logout.exec, logout)

var prefix = 'on'
(window.attachEvent || (prefix='', window.addEventListener))(prefix + 'unload', dispose)

當我覺得這樣就能交功課時，卻發現登出url響應狀態編碼爲302，而響應頭Location指向另外一個域的資源，而且不存在Access-Control-Allow-Origin等CORS響應頭信息，而XHR對象不支持Cross-domain Redirection，所以登出失效。
之前只知道XHR沒法執行Cross-domain資源的讀操做（支持寫操做）,但只覺得僅僅是不支持respose body的讀操做而已，沒想到連respose header的讀操做也不支持。那怎麼辦呢？既然讀操做不行那採用嵌套Cross-domain資源總行吧。而後有了如下的填坑過程:

第一想到的就是嵌套iframe來實現，當iframe的實例化成本過高了，致使iframe還沒來得及發送請求就已經完成unload過程了；
因而想到了經過script發起請求, 由於respose body的內容不是有效腳本，所以會報腳本解析異常，若設置type="text/tpl"等內容時還不會發起網絡請求；另外iframe、script等html元素均要加入DOM樹後才能發起網絡請求;
最後想到HTMLImageElement，只要設置src屬性則立刻發起網絡請求，並且返回非法內容致使解析失敗時仍是默默忍受，特別適合此次的任務:)

因而獲得下面的版本

;(function(exports){
  exports.Logout = Logout

  function Logout(url){
    if (this instanceof Logout);else return new Logout(url)
    this.url = url
  }
  Logout.prototype.exec = function(){
    var img = Image ? new Image() : document.createElement("IMG")
    img.src = this.url
  }
}(window))

[before]unload致使性能降低？

如今咱們都明白如何利用[before]unload來作資源釋放等善後工做了。
但請記住一點：因爲[before]unload事件會下降頁面性能，所以僅因爲須要作重要的善後或不可逆的清理工做時才監聽這兩個事件。
之前，當咱們從頁面A跳轉到頁面B時，頁面A的全部資源將被釋放（銷燬DOM對象,回收JS對象, 釋放解碼後的Image資源等）;後來各大瀏覽器廠商分別採用bfcache/page cache/fast history navigation機制，將頁面A的狀態保存到緩存中，當經過瀏覽器的後退/前進按鈕跳轉時立刻從緩存中恢復頁面，而不是從新實例化。如下狀況將不被緩存起來：

監聽unload或beforeunload事件;
響應頭Cache-Control: no-store;
對於採用HTTPS協議的響應頭，知足如下一個或以上：
3.1. Cache-Control: no-cache

3.2. Pragma: no-cache
3.3. 存在Expires超期的

發生跳轉時，頁面存在未加載完的資源
旗下iframe存在上述狀況的
頁面在iframe中渲染，當用戶修改iframe.src加載其餘文檔到該iframe時

所以若執行不可逆的清理工做時，對於現代瀏覽器而言咱們應該訂閱pagehide事件，而不是unload事件，以便利用Page Cache機制。
事件發生順序：load->pageshow->pagehide->unload
pageshow和pagehide的事件對象存在一個persisted屬性，爲true時表示從cache中恢復，false表示從新實例化。
經簡單測試發現chrome默認沒有啓用該特性，而Firefox則默認啓用。實驗代碼：

// index.html
window.addEventListener('load', function(){
  console.log("index.load")
  window.test = true
})
window.addEventListener('pageshow', function(e){
  console.log("index.pageshow.persisted:" + e.persisted)
  console.log("index.test:" + window.test)
})

<a href="./next.html">next.html</a>

// next.html
window.addEventListener('load', function(){
  console.log("next.load")
})
window.addEventListener('pageshow', function(e){
  console.log("next.pageshow.persisted:" + e.persisted)
})

運行環境：FireFox
操做步驟：1.首先訪問index.html，2.而後點擊連接跳轉到next.html，3.而後點擊瀏覽器的回退按鈕跳轉到index.html，4.最後點擊瀏覽器的前進按鈕跳轉到next.html。
輸出結果：

// 1
index.load
index.pageshow.persisted:false
index.test:true
// 2
next.load
next.pageshow.persisted:false
// 3
index.pageshow.persisted:true
index.test:true
//4
next.pageshow.persisted:true

看到頁面是從bfcache恢復而來的，因此JS對象均未回收，所以window.test值依然有效。另外load僅在頁面初始化後纔會觸發，所以從bfcache中恢復頁面時並不會觸發。
假如在index.html上訂閱了unload或beforeunload事件，那麼該頁面將不會保存到bfcache。
另外經過jQuery.ready來監聽頁面初始化事件時，不用考慮bfcache的影響，由於它幫咱們處理好了:)