C# and JQuery, strange behaviour on postback

Question

Hi, I have an asp.net web site in which I'm trying to insert some ajax call to gain some loading time on page opening.

SCENARIO: On page A.aspx I use JQuery $(document).ready() event to trigger an ajax call (via the ajax() method). The ajax call targets B.aspx page (in the same site) which renders a portion of html that I eventually inject into the existing markup of A.aspx.

After that ajax call the page is not able to fire __dopostback event properly anymore. In fact if I try to click to a pre-existing control in page A.aspx that should trigger a page postback B.aspx page is opened instead.

I tried to move B.aspx to another site, which runs in another application pool, but __dopostback call on A.aspx still tries to open B.aspx .

Here's the call:

    
    $(document).ready( function() {
        $.ajax({
            type: "GET",
            url: "./B.aspx",
            data:"username=xxx",
            dataType: "text",
            error: function(XMLHttpRequest, textStatus, errorThrown){
                $('#agentResultErrorContainer').html('Error... ' + errorThrown);
            },
            success: function(data){
                $('#agentsResultContainer').html(data);
         }
        });
...
...
...
    }

Other details: Site runs under .net 2.0 platform

Answer 1

What does B.aspx render? If it's a webform, then this is probably expected behaviour, as the hooks for __dopostback will be updated to point to B.aspx.

Answer 2

The way you're doing it here, you end up with two of every element ASP.NET: two viewstates, two forms (with the name name and id), JavaScript functions, etc (see also this similar question). This, by the way, has nothing to do with the app-pool, it all happens client-side.
Also, even if you do a successful postback, you're likely to get various exceptions.

The solution? Don't do it. You can move on to MVC, where this is more comfortable, or more likely, you can create b.ashx (a general handler), that returns clean HTML (with no postbacks), and handle the logics using Javascript, or using the fields being posted to a.aspx. (you can add input fields and read them using Request.Form).

Another note: I doubt this approach will get you a better user experience - they still have to wait for the page to load, and it is likely to be even slower. I'll give you the same advice I gave at the other question - a user control is the simplest solution here.

Answer 3

@Kobi, @David: Thanks a lot for your explanations. There were form and viewstate replication also on the async-called page and were obviously injected on the original markup, causing the mess.

@Kobi: I agree with your advice, moving to other paradigm, such as MVC, would surely be more effective, but unfortunately by now I can only try these small changes, leaving everything else as is.

Answer 4

Assuming you leave both pages on the same domain, I would suggest the following:

1. With regard to the $.ajax url property "./B.aspx", is the "." necessary? I am used to using full relative paths (i.e. "/B.aspx" by itself).

2. Have you tried firing up your debugger, and placing breakpoints on Page_Load for both A.aspx and also B.aspx? It may help you to deduce where the request is taking place and what is happening.

3. Are you using a plug-in like Firebug (for Firefox), or Web Developer Tools (for IE8)? These tools will help you pinpoint any javascript errors. I find that if a Javascript error is fired on a page, it may prevent future javascript functions (such as __DoPostback) to not occur because the script as abnormally ended.

Hope those suggestions help.