AutoPostBack: true vs false

Question

Before I begin, I have already seen this question about a very similar topic (as well as this one and this one), none of which answer my question completely. I already understand the concepts presented in these questions/answers, but I have more questions.

A) What happens if you have multiple controls with AutoPostBack="false" and you change a number of them before a postback? Take the following brief example (assume that everything else needed for the page is written correctly and trivially; e.g., Page_Load):

Default.aspx:

<asp:DropDownList ID="ddlFoo" runat="server" 
    OnSelectedIndexChanged="ddlFoo_Changed" AutoPostBack="false" >
    <asp:ListItem Text="a" />
    <asp:ListItem Text="b" />
    <asp:ListItem Text="c" />
</asp:DropDownList>
<asp:DropDownList ID="ddlBar" runat="server" 
    OnSelectedIndexChanged="ddlBar_Changed" AutoPostBack="false" >
    <asp:ListItem Text="1" />
    <asp:ListItem Text="2" />
    <asp:ListItem Text="3" />
</asp:DropDownList>
<asp:Button ID="btnQux" runat="sever" Text="Click for PostBack" OnClick="btnQux_Click"

Default.aspx.cs:

protected void ddlFoo_Changed(object sender, EventArgs e)
{
    Response.Write("ddlFoo changed to " + ddlFoo.Text + ". ");
}
protected void ddlBar_Changed(object sender, EventArgs e)
{
    Response.Write("ddlBar changed to " + ddlBar.Text + ". ");
}
protected void btnQux_Changed(object sender, EventArgs e) { }

Now, say you change ddlFoo to 3 and then ddlBar to b. Then, you click btnQux. You get the following output from Response.Write after clicking:

ddlBar changed to b. ddlFoo changed to 3.

Why does this happen? Do the OnSelectedIndexChanged methods get put into a stack to be called once a postback happens?

B) Why does my webpage load much more quickly when I use this approach and set AutoPostBack="false" for most of my controls? To be specific, I did this for a CheckBox, a DropDownList, and a TextBox in a GridView, which retrieved ~1200 rows and 27 columns of data and took 10s in VS2008 debug mode versus 310s before. Why would the load/refresh time be so much faster?

EDIT: I released the code earlier this afternoon, and there was no significant difference between the load time of the old (AutoPostBack="true") and new (AutoPostBack="false") versions. I think that perhaps the debugger was doing something extra, which caused the large jump in load time. A better way to rephrase question B) might be this then: What could the debugger have been doing to cause this large jump in load time?

score 7 · Accepted Answer · edited Dec 31 '15 at 23:29

7

Warning: I'm no ASP.NET expert... If this turns out to be garbage, I'll delete it :)

A) I believe you will see the new values of all the controls, whenever the postback ends up happening, including all the change events, just as you described. The values have changed, after all - the AutoPostBack just affects the timing (and whether the postback occurs at all, of course).

B) There's more Javascript in the HTML delivered with AutoPostBack = True on all the controls, but not enough to make that enormous difference. As noted in your edit, it looks like that was a transient issue anyway - we can't really explain transient issues without more diagnostics.

edited Dec 31 '15 at 23:29

Mykola

3,343
6
23
39

answered Jul 31 '13 at 19:09

Jon Skeet

1,421,763
867
9,128
9,194

That's quite precise, actually. `AutoPostBack` will just force the page to post to the server. If there's an event handler binded to a control, the event will be stacked despite `AutoPostBack="false"`. http://msdn.microsoft.com/en-us/library/8cb3cz8e(v=vs.100).aspx – Andre Calil Jul 31 '13 at 19:32
I took a look at the source code as you suggested. With `AutoPostBack="true"` on my controls the code was 4.98 MB; with it set to false, it was 4.57 MB. There is certainly a difference between their sizes, and I did notice that there is a considerable amount of JavaScript in the true version. Thank you for the insight – wlyles Jul 31 '13 at 20:24
@wlyles: That difference in size doesn't really explain that much of a time difference though. I think you ought to look further into where the time is going. How are you measuring it? Is that time before the response is served, or time taken before it finishes rendering on the browser? (In which case the time may be spent executing Javascript on the browser, but that's a lot of time...) – Jon Skeet Jul 31 '13 at 20:28
@JonSkeet yeah, that's what I though too. It shouldn't have made such a difference. I timed it simply from the time that I pressed F5 (Start Debugging) until the page would allow me to click on the controls to change their values. It seems as if a majority of the time goes into rendering, as the `
` elements at the top of the page and the first few rows of the `GridView` are visible within a few seconds, but the rest of the `GridView` takes quite a while
– wlyles Jul 31 '13 at 20:42
I released the code earlier this afternoon, and there was no significant difference between the load time of the old (`AutoPostBack="true"`) and new (`AutoPostBack="false"`) versions. I think that perhaps the debugger was doing something extra, which caused the large jump in load time. – wlyles Jul 31 '13 at 23:25

Vano Maisuradze · Answer 2 · 2013-07-31T19:23:57.440

You can use Fiddler to see what data is moving between client and server.

A. With fiddler you can easily see what data is sent to the server.

For example:

If you have DropDownList ddlFoo, when you click on button, you actually post this information:

POST http:// [server]:[port]/[resource.aspx] HTTP/1.1 Host: [server]:[port] [Headers...]

_VIEWSTATE[viewstate data stored in html as hidden field value]&_EVENTVALIDATION=[event validaion data]&ddlFoo=selecteItem&button1=ButtonText

When ASP.NET receives request, it compares ddlFoo's value and invokes it's event.

B. When you set AutoPostBack to true, then this javascript function will be generated:

function __doPostBack(eventTarget, eventArgument) {
    if (!theForm.onsubmit || (theForm.onsubmit() != false)) {
        theForm.__EVENTTARGET.value = eventTarget;
        theForm.__EVENTARGUMENT.value = eventArgument;
        theForm.submit();
    }
}

And onchange attribute will be added to ddlFoo. So whenever you change DropdownList item, onchange event will be fired and __doPostBack function will be called, which will auto post back to the server.

score 1 · Answer 3 · answered Jul 31 '13 at 19:31

Both answers you have gotten so far are correct. The simplified version of it is this:

A) When the form is finally POST'ed to the server, the server compares the form's current state with the ViewState and responds accordingly.

B) Enabling AutoPostBack causes javascript to be generated, and this javascript submits the form (which then triggers the postback).

score 1 · Answer 4 · answered Jul 31 '13 at 20:18

1

Why does this happen? Do the OnSelectedIndexChanged methods get put into a stack to be called once a postback happens?

Events that do not immediately post back (in your case ddlFoo_Changed and ddlBar_Changed) are cached.

Then those cached/pending events are raised along with btnQux's click event, when a page is posted back (by btnQux's click event).

You can read more here - ASP.NET Server Control Event Model

answered Jul 31 '13 at 20:18

Win

61,100
13
102
181

Thanks for the link, that is very useful for my first question – wlyles Jul 31 '13 at 20:26

AutoPostBack: true vs false

4 Answers4