0

I am writing JavaScript for a plugin that will be used on clients' sites, and need to use a beforeunload handler to store some information to the user's cookies or localstorage for tracking purposes.

However, since I don't control the clients' sites, I'm concerned about the scenario where the client's page has already defined a beforeunload handler before we set ours. In particular, I'm worried about the case where the client's JavaScript creates a 'beforeunload' handler that returns a string to create an 'Are you sure you want to leave this page?'-style popup, and the possibility that adding our handler after that may destroy or otherwise interfere with this functionality.

Based upon a little experimentation in the console in Chromium, it seems that if I add handlers using jQuery(window).on('beforeunload', handler), then all the handlers get executed in the order they were added and then the existence and content of any confirmation dialog is determined solely by the final non-undefined return value. So if the last handler added with an explicit return returns null, no message is shown, and if it returns a string, then a confirmation dialog with that string as its content is shown. This is the behaviour I want; it means that as long as I return undefined from the beforeunload handler that I add, I shouldn't break any of our clients' code.

Can I rely upon this behaviour across all browsers, though? How about if the client added their original beforeunload handler via a mechanism other than jQuery, like explicitly assigning to window.onbeforeunload or using window.addEventListener? How is jQuery handling the assignment of multiple handlers behind the scenes?

Mark Amery
  • 143,130
  • 81
  • 406
  • 459
  • `if (window.onbeforeunload) { oldBeforeUnload=onbeforeunload; onbeforeunload=function() { yourstuff(); oldBeforeUnload() }` – mplungjan Apr 11 '13 at 15:03
  • @mplungjan Well, firstly, that'd need to be `return oldBeforeUnload()`, not just `oldBeforeUnload()`, or you're breaking existing functionality. Secondly, I don't know whether this approach is necessary or whether adding the handlers using jQuery already behaves in something like this way - hence the question. I also don't know whether, if the client is using jQuery, your approach will break their ability to remove a handler using the jQuery `.off` method - I suspect it does. – Mark Amery Apr 11 '13 at 15:17
  • It was just to give an idea. You may need to do both – mplungjan Apr 11 '13 at 15:19
  • You should just document that you add stuff to `onbeforeunload` and the clients that use your library should take care of it if he has events of his own to add. I promises you that you can't think of all the ways the client will abuse your library or the DOM :) – TheBrain Apr 11 '13 at 15:45
  • @TheBrain Sure, I can't handle every case, but my concern is that I might inadvertently blow stuff up even in the case where the client is adding beforeunload handlers in a standard, sensible way. – Mark Amery Apr 11 '13 at 16:32

1 Answers1

0

what if you do it like this

 var x = window.onbeforeunload
 window.onbeforeunload = function() { 
       // do your stuf
       if (x) return x();
 }

so this way you'll return whatever the initial event handler was suppose to return.

TheBrain
  • 5,528
  • 2
  • 25
  • 26