PageRequestManagerServerErrorException in FireFox

本文转自：http://blogs.teamb.com/yaminov/2008/07/30/pagerequestmanagerservererrorexception-in-firefox/

 

One of the problems we had to face when adding event support to CDN was the additional time it takes to check if there are any events scheduled in days displayed in the navigation calendar. To improve client-side performance, I used an UpdatePanel and a Timer to delay loading that information. The calendar is first rendered without highlighting days with events, but when the Timer’s Tick event is triggered, the server searches for events in the specified time range and refreshes the calendar.
A lot of us on the CDN team use FireFox 3 as our default browser, and we noticed something weird. If we navigated away from a CDN page before the calendar had been updated, we’d get the following error:

Sys.WebForms.PageRequestManagerServerErrorException: An unknown error occurred while processing the request on the server. The status code returned from the server was: 0

Now, the error message is misleading. This isn’t really a server-side error, but a client-side error. You can trap ASP.NET AJAX client-side errors using the PageRequestManager class, but I didn’t want to ignore other errors. I ended up adding the following script to the page:

<script type="text/javascript">
  if (!document.all) {
    window.onbeforeunload = function() {
      Sys.WebForms.PageRequestManager.getInstance().add_endRequest(endRequest);
    }
  }

  function endRequest(sender, e) {
    err = e.get_error();
    if (err){
      if (err.name == "Sys.WebForms.PageRequestManagerServerErrorException") {
        e.set_errorHandled(true);
      }
    }
  }
</script>

The script adds an event handler for the window’s beforeunload event, which FireFox supports and - fortunately - runs before the error (the unload and pagehide events run too late). The handler registers a handler for the endRequest event, which is raised after the AJAX request is finished and can be used to handle errors. Since at this point we’re already navigating away from the page, it should be safe to simply ignore the error.

A Google search returned only one mention of this problem, but no solutions. It was mentioned that this problem might have been fixed in .NET 3.5, but unfortunately most of our ASP.NET applications are still on 2.0.