No more hijacking of __doPostBack in Whidbey

Note: this entry has moved.


Intercepting form submissions


A few months back I was asked by a developer on my team about the best way to make sure a function was always called before form submission. This is a recurring problem among web developers. Listening for form.onsubmit (by using Page.RegisterOnSubmitStatement ) is just not enough because it won’t fire when the form is submitted programmatically as ASP.NET’s __doPostBack function does:


     function __doPostBack(eventTarget, eventArgument) {

          var theform;   

          // …

          theform.__EVENTTARGET.value = eventTarget.split("$").join(":");

          theform.__EVENTARGUMENT.value = eventArgument;

          // this won’t cause the form.onsubmit event to fire




This means that for any given page in which the __doPostBack function is present we need another way to intercept form submissions. So, I told the developer to hijack __doPostBack


Hijacking __doPostBack      


A common technique, as we can’t modify __doPostBack to make it call our custom function, is to just hijack it:


// save a reference to the original __doPostBack

var __oldDoPostBack = __doPostBack;

// replace __doPostBack with another function

__doPostBack = AlwaysFireBeforeFormSubmit;


The implementation for our AlwaysFireBeforeFormSubmit should look like:


function AlwaysFireBeforeFormSubmit (eventTarget, eventArgument) {

// do whatever pre-form submission

// chores you need here

// finally, let the original __doPostBack do its work

return __oldDoPostBack (eventTarget, eventArgument);



Multiple hijackings is (usually) a bad thing


Last week, pages on one of our web apps started breaking. What happened was that this developer passed my recommendation to another developer. They both were developing controls and they both were interested in getting a chance to run a function before form submission. Now… pages including both controls were breaking because of the two hijacking attempts.


How can the hijacking of __doPostBack be coordinated between different devs on the same team or better yet between any devs in the entire world? :-) Easy enough: the framework should support it.


Hijacking with first-class support from the framework


This is exactly what I’ve done for our custom framework. Basically I’ve told every dev on every team on the project to never, never, ever hijack _doPostBack by themselves. Instead they will simply call Page.RegisterOnSubmitStatement and the framework will make sure their function get always called before a form submission.


Our framework now includes its own hijacking of __doPostBack and it’s the only one allowed to do so. The “impostor” function makes sure form.onsubmit gets always called by checking for its existence and then calling it. Pretty much like Whidbey will do.


Whidbey modifies __doPostBack


The ASP.NET team heard the many voices that were raised during last years regarding this topic and so decided to add support for this in Whidbey. Good news is this hijacking won’t be necessary anymore (so you can discard the all the previous paragraphs…) because the __doPostBack function has been modified to explicitly call form.onsubmit, something like this:


     function __doPostBack(eventTarget, eventArgument) {

          var theform;

          // note how form.onsubmit is being called explicity

          if (theForm.onsubmit == null || theForm.onsubmit()) {

               theForm.__EVENTTARGET.value = eventTarget;

                theForm.__EVENTARGUMENT.value = eventArgument;







  • Hello, can you show ur code? I'm trying to achieve the same thing.

  • FINALLY! I've seen all sorts of work arounds to dealing with the __doPostBack.

    I've mostly seen assigning a client side click event to a web control that looks like this:

    Button.Attributes.Add("onClick", "if (foo() == true) ")

    This creates the following in HTML:

    <Button onClick="if (foo() == true) __doPostBack">

    This was used to call a common foo() function for anything that would cause a postback, but had to be added for each control that needed to fire it. I had not seen the highjacking as you showed above. I kept thinking this was a bad idea given that it relied on the framework NOT adding a semicolon in front of the __doPostBack statement on the rendering.

  • Victor:

    I've also failed to implement the hijacking without getting some jscript errors...

    can you post your code?



  • Here's another way I found to do it. Basically, override the submit() method on the form.. Add these 2 lines to your control, and the onsubmit() event will be fired. Then, you can simply remove them when Whidbey fixes the issue..

    Page.RegisterClientScriptBlock("ViewstateSubmitHandler", "<script language=JScript>function ViewstateForm.submit() {;}</script>");

    Page.RegisterClientScriptBlock("ViewstateSubmitButton", "<input type=submit id=submitButton style=\"display: none;\">");

  • Victor,

    I was going through your example of avoiding

    the __doPostBack Problem. As I am new to developing .Net controls I am not sure where to put the code to avoid the problem.

    will I get more help on this?

    Let me explain what I am doing.

    I am using link buttons inside repeater so that

    PRODUCTS are listed with the productId as a hyperlink. so when the user clicks the link the screen to product details are listed to allow the user to edit.

    but when the user (@ the moment myself)clicks

    on the link the __doPostBack is fired

    and nothing works as what I have wanted.

    Hope you will explain where exactly I should place the function AlwaysFireBeforeFormSubmit

    so that I can implement your concept.



  • I'd like to know why we have to wait for WHIDBEY for dumb little fixes like this, instead of minor service packs for .NET.

  • Hi Eric,

    Sorry I don't have an answer for you :-)

  • Victor,

    if you're getting javascript errors running the

    above code try completely qualifying the function names:

    // save a reference to the original __doPostBack

    var __oldDoPostBack = window.__doPostBack;

    // replace __doPostBack with another function

    window.__doPostBack = window.AlwaysFireBeforeFormSubmit;

  • Only you must use the override with the arguments... That's all:


    var __oldDoPostBack

    function reDirigirPostBack ()


    if (typeof __doPostBack != "undefined")


    // save a reference to the original __doPostBack

    __oldDoPostBack = __doPostBack;

    // replace __doPostBack with another function

    __doPostBack = ejecutarPrevioEnvio;



    function ejecutarPrevioEnvio (eventTarget, eventArgument)


    mostrarMensajeEmergente ();

    // Si es necesario se tendria en cuenta el onsubmit de cada pagina con

    // if (theForm.onsubmit == null || theForm.onsubmit()) {

    return __oldDoPostBack (eventTarget, eventArgument);


    /* Asignaciones previas */

    window.onload = reDirigirPostBack;

  • When I call __doPostBack in Asp.Net 2.0 asynchronusly, I need to fire an function in Javascript after the server does its thing. Is there a delegate function I can specify in Javascript or something that fire after __doPostBack is done firing??

  • There seems to be a problem with the if statement in Whidbey. if (theForm.onsubmit == null || theForm.onsubmit()) { ... } as Firefox returns false for both conditions. This is because Firefox only understands "onSubmit" with a capital "S" in submit. The statement "if (theForm.onSubmit == null || theForm.onSubmit()) { ... } " works on both platforms. So we still have a problem. Any ideas, solutions?

  • Comments (required)*

Comments have been disabled for this content.