unload And beforeunload Events And How To Easily Debug Them Both!
By: Gal Weizman
Tags: Chrome, Research, Debugging, Web Security, JavaScript

tl;dr — if you’re only here for the trick of how to set a breakpoint and actually debug unload and beforeunload event listeners, go straight to “The Trick To Successfully Debug unload / beforeunload Event Listeners” section below.

As I often do, I was looking for potential vulnerabilities in well known websites and web applications. There is a specific one that I have reasons to believe that might be vulnerable to a serious XSS exploitation.

At some point in the process, I realized that the part that might be vulnerable to XSS is executed by an unload event listener that was registered by some javascript code in the website. This was where I had to debug to be able to tell whether I found something interesting here or not.

So I set a breakpoint where the code that is supposed to be fired by the unload event is, and reloaded the page to allow my Google Chrome Browser stop at this breakpoint of mine, letting me debug it.

For those of you who have enough javascript experience, the following will not shock you at all: the browser ignored my breakpoint completely and reloaded the page normally.

That’s kind of annoying. I mean, any javascript code that is intended to execute under this event executes perfectly fine — whether it’s console.log() , localStorage.setItem() or any other standard action. So what’s wrong with my breakpoint? or placing a debugger; command? Why don’t these work?

In order to understand this behavior, it makes sense for us to first understand these events. The purpose of these events is to enable a website to execute pre-configured actions right before it, unloads and when it unloads.

Or, to be more specific, as mentioned in MDN: “The beforeunload event is fired when the window, the document and its resources are about to be unloaded” and “The unload event is fired when the document or a child resource is being unloaded”. (which means it’s not about the website as much as it is about any window that lives within the website, whether it is the top frame or an iframe )

So let’s try to list the different properties of these two events and compare them:

Order: beforeunload will always fire before unload event (makes sense, right?)

Purpose: The beforeunload event triggers right before unloading of the window has begun. unload would trigger while unloading of the window is taking place.

Cancelable: The beforeunload event can be canceled by user interaction:

The above example will trigger a popup asking the user whether they are sure they want to leave the site or not, and in case they choose not to leave, the beforeunload event will be canceled, the unload event will never even initiate, and the page will not reload. On the other hand, that wouldn’t happen for an unload event — once it is fired, there is no way to prevent the window from unloading.

Supporting objects: Both beforeunload and unload events can be registered to be listened to by window , HTMLElementBody and HTMLFrameSetElement

It is worth mentioning that the unload properties of all three (the window , the body and the frameset ) point to the same place (same goes for beforeunload ):

Oh, and for those of you who wonder “what in the world is a frameset ?” — don’t worry about it. It's this super old and deprecated element that is no longer in use at all. In fact, it is currently defined as obsolete, which means it could be gone in any new version of any major browser any time!

Prototype: Whereas unload is a normal event that inherits from Event , beforeunload has its own prototype, BeforeUnloadEvent . This is in order to implement the beforeunload event’s unique property returnValue , which allows the registered event listener to display the “Are you sure you want to leave this site?” dialog box.

So How Can One Debug A beforeunload / unload Event Listener?

And now for the cool part! As I was saying at the beginning, debugging these events is pretty tricky because, when you think about it, you’re not supposed to be able to. The purpose of the unload and beforeunload events is very clear: Execute a set of preconfigured actions before and when a page unloads. All synchronous actions are guaranteed to fully execute, but when it comes to asynchronous actions that are initiated by synchronous actions inside the event listener, the browser is more like “I’ll do my best to execute all your actions, but when the unloading event finishes I cannot promise you anything”.

But does the browser agree to execute any type of action? The answer is no. There are some types of actions that by spec are not allowed to be executed within a beforeunload / unload events listeners. alert() is one example, but the most relevant one is debugger; (neither is setting a breakpoint using the devtools).

So setting a breakpoint in the listener, setting a debugger; statement or anything else really — would all be ignored by the browser, thus making debugging of the unload / beforeunload event kind of impossible.

The Trick To Successfully Debug unload / beforeunload Event Listeners

So back to my story… After a few hours of trying to successfully debug the suspicious unload event listener, I gave up for the night as it was very late. As I clicked the small x button in order to close the tab, expecting it to shutdown, I was amazed to finally see my breakpoint work!

Apparently there is one unloading flow in which the browser respects breakpoints and debugger; statements — not a normal reload of the page, but an actual attempt to shut its tab down completely!

I still went to sleep after that because it really was late — but ever since that I can easily debug unload / beforeunload event listeners!

Tips For Researchers

Keep an extra tab open in your Chrome window — once you use the trick to debug listeners, although you’d be able to debug them, you will not be able to prevent the tab from shutting down. It is easier to repeatedly do so while working at the same window, which would only be possible if the closing tab is not the only tab in the window. Google Chrome Browser — I haven’t checked whether this trick works on other browsers than Chrome, mostly because I don’t see a reason to debug javascript code in any other browser (yeah, I said it).

It might work on other browsers though — again, never even checked. Understand your case first — if the code you attempt to debug is, for some reason, session-based, closing the session (by using the trick above and closing the tab) each time might create a different flow from what you actually try to research — take that into consideration when debugging!

Tips For Developers

No long actions inside these listeners — although practically you can synchronously do what ever you want inside the listeners, it is bad practice! Avoid long actions in order to make sure you don’t prevent the user from smooth unloading of your website. Use sendBeacon() in case you must send data before unloading — sometimes it makes sense for a website to want to send some POST data when the page is about to unload. In order to successfully do so, sendBeacon() was invented. (like, seriously, it was literally invented for this case) so make sure to use that if you want to know for sure your data is sent without expecting a response.

To Sum Up

Hope this made sense and helped you understand these two unique events, their purpose and their differences. Also, I hope you find that debugging trick useful — I sure did!

If I have missed out on anything or am wrong with anything of what I’ve said in this article, I would love to hear it so I can correct myself and keep this post as accurate and as helpful as possible!

Oh, and sorry for no jsfiddle demos.. for some reason beforeunload and unload events didn’t work very smoothly with it.

I recommend that you to just copy-paste the snippets above in Chrome’s devtools console in any website and see it for yourselves.

Edit: The builtin way to debug any registered event listeners in chrome devtools has come to my attention as another way to debug all beforeunload event listeners. It is indeed a great builtin way to do so, but: