In my defense, the pages I’m thinking of are essentially one big form, and if you leave the page, you’re usually either submitting or never coming back (e.g., closing the window). The onunload is there full-time for these pages right now (I might fix!), but navigating away without submitting and then coming back is rare enough that slowing down that case is bearable, if sloppy.

Thanks much for considering history.navigationMode and for wading through my longwinded comment. I think you distilled it right: some folks could use an “explicit, semantically precise” way to tell the browser they’ve destroyed the DOM.

You’re also right that we’ll inevitably sometimes use it in ways that make the page slower than is strictly necessary — sorry. Browser developers put up with a lot of nonsense from Web developers — we owe you one. Or rather, we owe you many many.

If there were some other programatic way to disable the PageCache, that would still be desirable to the unload handler. Semantically, the “unload handler” and “I want to disable the PageCache!” are two completely different things.

Opera invented “history.navigationMode” for this reason. We might consider implementing that (https://webkit.org/b/29739) but I would shudder if developers just started flipping the switch at page load and left it on the whole time!

Of course, maybe that wouldn’t be much different than the situation today…

As a Web developer, I’ve sometimes specifically wanted to turn off the back/forward cache. For example, I sometimes have an onsubmit handler — not an onunload! — that leaves the page in an unusable state, e.g., by disabling the submit button. (That means my form is broken if the user starts to submit then immediately hits Esc.)

When the user hits Back, I’d rather they see the page as it was at load time (but with form data filled in), not as it was after submit. In an ideal world, I’d want them to see the page as it was just before they hit Submit, but that’s not feasible to do.

Right now, I avoid the page cache by adding an empty onunload handler to disable the page cache, but that will break. As alternatives, I could add a cache-control header, or call window.location.reload() in onpageshow if evt.persisted. Both approaches have the downside of forcing the page’s HTML to be redownloaded as well as skipping the page cache. What do you all think is the best thing to do if I want to opt out of the page cache but am OK with the browser using the cached HTML?

I know there are more elegant options than opting out of the page cache, like just not messing with the form in my onsubmit handler or “fixing” the form in onpageshow. Still, it seems interesting to ponder what to do if you want to opt out of the page cache; surely someone out there will.

As for my thoughts on the issue, here’s a partial reposting from https://bugs.webkit.org/show_bug.cgi?id=29021

You could save the page to the page cache, then fire the unload event and navigate away. If back is clicked, the page will be returned in the state it was BEFORE unload was fired. This gives you the best of both worlds. (this was suggested in Chrome’s bug tracker)

Also, (and webkit may do this already) you need to make sure the element that the mouse is currently over has its mouseout event fired, else you might get sticky hover effects.

Jake.