Post

naugtur
@naugtur.pl

I remember back in 2012 I'd send ux testing data in unload and try to run useless loops to delay closing the page so that it reaches the server. It was increasingly hard because browsers would limit what you can do to prevent that delay 😅

Barry Pollard
@tunetheweb.com

People do not open a page to read/interact with, and then close it cleanly. The modern web is more complex with pages backgrounded, often silently killed in the background (by the OS AND by users) or navigated away from before restoring by the bfcache by going back. Unload did not fire for those.

Barry Pollard
@tunetheweb.com

When a tab is hidden (and visibilitychange happens) you should take that as the last opportunity to reliably fire events (save state, fire analytics...etc) rather than assume unload will fire late (it often doesn't). APIs like fetchLater also help here. Let me know if you've any questions!

Craig Francis
@craigfrancis.bsky.social

I’ve got a really old page/form for basic data editing. It records when the page was opened. If anyone else tried to open that page it shows them a warning message. It used the unload event to more cleanly remove the lock (also had a timeout). I need to update it to use visibilitychange now?

Barry Pollard
@tunetheweb.com

The oagehide event is the nearest equivalent event for this use case. It fires on navigating away rather than just on tab switch. And yes it’s badly named IMHO. It’s just as unreliable as unload but is newer so assumption is web pages will use it in conjunction with pageshow.