6

In 2007 in a post called "Mastering The Back Button With Javascript" Patrick Hunlock claimed that just including an onbeforeunload handler in a page will stop caching. (I guess browser caching.) He was very emphatic about it:

Just having an unbeforeunload event handler -- regardless of whether or not it actually does anything, regardless of whether or not you spawn a dialog box or not, even if the entire function declaration consists entirely of just { } -- just defining an event handler will prevent the page from being cached -- ever.

As a matter of fact, even if you allow page caching, the page will be not be cached. Having an onbeforeunload event means the page will be re-built every single time it is accessed. Javascripts will re-run, server-side scripts will be re-run, the page will be built as if the user was hitting it for the very first time, even if the user got to the page just by hitting the back or forward button.

Funny thing is I can't find any mention anywhere else of this, apart from one or two people who refer to Hunlock's post. Can anyone clear up this question? Is it really true, or can I safely use that event?

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
And Finally
  • 5,602
  • 14
  • 70
  • 110
  • I have no idea, but the lack of references/documentation makes me think it's no good. Even if it were fine to use, just don't. Use proper caching techniques to accomplish what you want – Ian Jun 10 '14 at 15:56
  • Thanks Ian - I'm not trying to mess with the caching, just want to know if there's a risk I'll break it. – And Finally Jun 10 '14 at 16:17
  • There are a lot of google references to firefox and safari not using the cache when the back button is used to leave or return to a page, if there is an unload or onunloadhandler. Here is one- http://madhatted.com/2013/6/16/you-do-not-understand-browser-history – kennebec Jun 10 '14 at 16:57
  • Thanks kennebec - very interesting reference there to a cache in FF and Safari which "stores the current state of the DOM in memory" for re-rending if you click the back button. It says an unload handler on the window will break that caching. – And Finally Jun 10 '14 at 22:24
  • Not that it matters a great deal anymore, but IE6 would not store the page state either if the unload handler was used. I don't know if IE7 or 8 is the same way. – Jeremy J Starcher Jun 10 '14 at 23:25
  • Thanks Jeremy, any more info on this is useful! Presumably IE6 IE7 were the current versions when Patrick Hunlock wrote his post. – And Finally Jun 11 '14 at 06:45
  • 1
    Hehe, I also bumped into that old "Mastering..." article today, and then I also wanted to do some fact-checking (exactly like in the question), and then Google just dropped me right here. :) – Sz. Jul 09 '15 at 22:47
  • Shows up here too https://developer.mozilla.org/en-US/docs/Web/Events/beforeunload – Dmitry Minkovsky Sep 02 '18 at 13:08

1 Answers1

0

For archaeologists, this was documented as a feature introduced in Firefox 1.5.

Be careful not to confuse the cache with the browser history (also known as the store) - page elements could be included in both. If the desired behavior is to force a browser to re-load an HTML page from the server if the Forward and Back navigation buttons are used (for example, because the page displays sensitive information, or content was changed using Javascript or Ajax calls) then Cache-control no-store should be used - or better use both no-store and no-cache.

Further reading:

radfast
  • 538
  • 1
  • 7
  • 14