Clicking a HtmlButton in an UpdatePanel using IE10 Standards mode causes double XMLHttpRequest postback

We have a .NET 4.0 WebForms app. One page has an UpdatePanel containing some HtmlButton controls. This was working correctly when the server was running on .NET 4.0.

When the server was upgraded to 4.5 we noticed that clicking the buttons would hang the browser. The spinner would show, and the user's session was essentially locked until the call timed out.

In the Network tab of the browser dev tools (F12) we observed:

• IE10 using Standards Doc Mode: Two calls are made to the server. The first one has no content and the Result is "(Aborted)". Fiddler reports a content-length mismatch. The 2nd call doesn't return until it times out.
• IE10 Compat View, Doc Mode IE7 standards: Only a single call is made to the server. All is fine.
• IE10 in any other mode (and also IE9) makes the 2 calls to the server with the first aborted and the 2nd hung/pending.
• Chrome: Two calls are made to the server, but the 2nd one succeeds.

Carrying out the same observations against a server running .Net 4.0 showed similar double-calls, but in no instance did the 2nd call hang.

I recreated this double-call behavior (apart from the hung 2nd call) by creating a new default .Net 4.5 WebForms app with an UpdatePanel, a Literal and a HtmlButton like this:

<asp:UpdatePanel ID="UpdatePanel1" runat="server">
    <ContentTemplate>
        <asp:Literal ID="myliteral" runat="server"></asp:Literal>
        <button id="htmlbtn" runat="server" OnServerClick="htmlbtn_Click"></button>
    </ContentTemplate>      
</asp:UpdatePanel>

The ServerClick event just puts the current time in the Literal.

This recreated the double-post behavior. I also tried using other types of button such as an ImageButton and they worked correctly only issuing a single call.

Does anyone know what is going on here? Is there any way to avoid the double-post using the HtmlButton? I am assuming that the 2 calls are related to the the hanging 2nd call, but that could be a bad assumption.

It turns out that their was some jQuery binding going on for each partial page request that wasn't being unbound before being bound again.

During jQuery's $(document).ready() I was setting up bindings to various elements. This function was being called during partial post backs caused by UpdatePanels. So in some cases what I needed to do was something like the following before setting up the binding again: $('#ctrl').unbind(); (There is probably a way to check if a binding exists and only add it if necessary.)

Also there is an textarea using a jQuery autoresize plugin on the page. When initialized the plugin adds a clone textarea off the page which is used to calculate the text height. On each partial page update a new one of these text areas was being created. Using Chrome's dev tools was useful to find this issue as I could see the DOM being changed in real time. I added some script to check for these existing text areas and clean them up.