First, let me explain why do we need to react when a page unloads. Under the context of the Modal Frame, this is not critical, but it provides a better user experience, and it may also prevent memory leaks. Here's what we want to do when a child document unloads:

1) Replace the title of the page that is being unloaded with a "Please, wait..." message on the modal frame title bar.
2) Hide the iframe and display a loading animation.
3) Unbind event handlers that have been bound from the parent window to properly manage the child window.

We could leave without it, however. In fact, not many people using the Modal Frame API has also installed the onBeforeUnload API. Curiously enough, these issues have not seen too much attention under the context of work on the Overlay module for D7.

Ok, so I hope we're in context now... :)

In regards to the unload event... it seems that browsers do not cache pages where an unload event has been installed, so it looks like a bad solution. Here, I would recommend reading the following article:

In short, the unload event should be fired when the page is destroyed from the browser. However, this may not happen as soon as it seems because the browser could move the page to its cache, and reuse it later, for example when pressing the back button of the browser. Since this behavior could break the page, it seems browser vendors decided not to cache pages that install an unload event. Please, see the above mention article for further information. It is explained much better than me here.

Ok, no problem. The Modal Frame API does not use an unload event. It uses a beforeunload event, with the help of the onBeforeUnload API. However, this means you'll have to install yet another module. Yes, there's a separate module implemented as an API because it is not possible to install several beforeunload event handlers at once, and this is because the way how this event works. If it returns a string, then the user will be prompted for confirmation to leave the page, and it is something impossible to coordinate this decission when this event is shared by more than one handler, so the last one installed wins. Hence, if we need different beforeunload event handlers, then we need an API. :)

However, the beforeunload event is not a perfect solution. Because a) we need yet another module, and b) while we could perform some action when this event fires, a different handler that's executed later on the chain of beforeunload handlers could force a prompt to the user, and the user could decide to remain on the page, and then we endup with an unstable page. So, the beforeunload event is not a perfect solution either.

Now, if you have read the above mentioned article, you'll have noticed there's an alterative. The pageshow and pagehide events. If you haven't already, read that article. It's pretty interesting. ;)

The problem is that these events do not come from the W3C standards. They were implemented by Mozilla for Firefox 1.5 (reference), and later adopted by other browsers. At least, Webkit based browsers (as described in the previously mentioned article), but... is there any body else? It seems to me this is bleeding edge stuff, and since there's not always many information available on these things, I'm afraid we need to guess a little...

So what can we do? How can we detect these events are supported? Ok, here's an idea:

We just need the pagehide event. So, we could install a pageshow event handler that we would use to set a flag. Later, once the page is fully loaded, we could install a pagehide event handler if supported, or else a beforeunload event handler. If pageshow/pagehide events are supported by Firefox and Webkit based browsers minimum, this means there's a pretty nice user base here that could benefit from a better Modal Frame UX without the need to install a separate module, and maybe someday we can get rid of the beforeunload stuff...

Sounds good? Thoughts?


markus_petrux’s picture

Title: Search for alternatives to the unload event » In search for alternatives to the unload event
dsnopek’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev
Issue summary: View changes

Let's continue this search as part of the Drupal 7 port! It'd be great to not have to port the onBeforeUnload module at all.