Welcome to Atalasoft Community Sign in | Help

UpdatePanel and Sys.Application.add_load Woes

I’ve found (as others have) an interesting problem with ASP.NET AJAX’s Sys.Application.add_load function.  It doesn’t quite work as expected in all browser environments, under certain conditions.

We have several ASP.NET based controls that use a lot of JavaScript on page load to initialize, and most of these controls are supposed to support being nested inside of an UpdatePanel.  For whatever reason, our composite controls’ initialization JavaScript manages to render after the call to Sys.Application.initialize.  Since our file based scripts load inside of the UpdatePanel, they are required to make calls to Sys.Application.notifyScriptLoaded as they load.

In Firefox 3, Safari 3 (on Windows), and Opera 9, the initialization scripts never run on the first load.  From my tests, I’ve concluded that Internet Explorer, Chrome, and FireFox 2 don’t have this problem.

Here are the basic conditions that cause this:

  1. Your script block renders after the Sys.Application.initialize block that ASP.NET injected into the page.
  2. You add your initialization script to the load event by using Sys.Application.add_load.
  3. You have at least one file based script file that calls Sys.Application.notifyScriptLoaded to notify the application that you’re waiting for scripts to load before you run your initialization script.

The solution that I’ve seen provided for edge cases such as this, states that you can define your initialization function anywhere on the page as shown:

function pageLoad(){
   // initialize your JavaScript here
}

From what I can tell, this works great for almost everyone that encounters this problem.  The documentation for this reserved named function is located in the ASP.NET AJAX Client Life-Cycle Events section.

This won’t help us unfortunately, since our controls are being used by developers that may need to use the same method.  Defining a pageLoad function on the page where someone else has already defined it will basically nullify the other function of that name.  So where does that leave us?  The DOM.

You may be thinking that I mean window.onload, and that’s sort of correct.  This event fires when the page is finished loading, but it only fires once, and doesn’t fire for every partial postback that the UpdatePanel does.  By using Sys.UI.DomEvent.addHandler, we can add an event handler that behaves the same way as Sys.Application.add_load.  Here’s the code:

function yourInit(){
   // initialize your JavaScript here
}
if (typeof(Sys) !== 'undefined'){
   Sys.UI.DomEvent.addHandler(window, "load", yourInit);
}
else{
   // no ASP.NET AJAX, use your favorite event
   // attachment method here
}

In my tests, this made the initialize event fire in the correct manner for all of the browsers that I tested.

If you have experience with this problem, and you found another way around it… please feel free to comment below.  Thanks!

Published Thursday, June 25, 2009 7:34 PM by David Cilley

Comments

Monday, June 29, 2009 4:50 PM by DotNetKicks.com

# UpdatePanel and Sys.Application.add_load Woes

You've been kicked (a good thing) - Trackback from DotNetKicks.com

Thursday, October 01, 2009 8:54 AM by vibstudio

# re: UpdatePanel and Sys.Application.add_load Woes

Hi Mr. Cilley,

in my opinion the Firefox's team is aware of the bug and has deliberately chosen not to remedy.

The following code works well with any browser except Firefox:

try {

   Sys.Application.add_load(SuggestionsBox1LoadHandler);

   function SuggestionsBox1LoadHandler() {

       SuggestionsBox("ctl00_ContentPlaceHolder1_SuggestionsBox1", ...

   }

}

catch(e) {

   try {

       $(document).ready(function() {

           SuggestionsBox("ctl00_ContentPlaceHolder1_SuggestionsBox1", ...

       });

   }

   catch(e) {

       alert(e.message);

   }

}

It 'a losing battle.

Anonymous comments are disabled