[HN Gopher] Deprecating the `Unload` Event
___________________________________________________________________
Deprecating the `Unload` Event
Author : feross
Score : 11 points
Date : 2023-08-10 17:48 UTC (5 hours ago)
(HTM) web link (developer.chrome.com)
(TXT) w3m dump (developer.chrome.com)
| paulddraper wrote:
| 1. Does the WhatWG standard matter anymore?
|
| 2. No mention of beforeunload. I imagine that is still good?
| lioeters wrote:
| According to the Chrome Developers page on the Page Lifecycle
| API [1], and the MDN page [2], it seems `beforeunload` is still
| OK to use.
|
| https://developer.chrome.com/blog/page-lifecycle-api/#event-...
|
| https://developer.mozilla.org/en-US/docs/Web/API/Window/befo...
|
| Both sites emphasize that it should be used only minimally, to
| attach and remove an event listener as needed, i.e., when there
| are unsaved changes.
|
| ---
|
| > ..On Firefox, the beforeunload event is not compatible with
| the back/forward cache (bfcache): that is, Firefox will not
| place pages in the bfcache if they have `beforeunload`
| listeners, and this is bad for performance.
|
| > However, unlike the `unload` event, there is a legitimate use
| case for the `beforeunload` event: the scenario where the user
| has entered unsaved data that will be lost if the page is
| unloaded.
|
| > It is recommended that developers listen for `beforeunload`
| only in this scenario, and only when they actually have unsaved
| changes, so as to minimize the effect on performance.
| matthews2 wrote:
| WhatWG is more like documentation of what browsers are
| currently doing, rather than a standard
| paulddraper wrote:
| Okay so this is an announcement WhatWG will change :)
___________________________________________________________________
(page generated 2023-08-10 23:02 UTC)