Why is my ASP.NET page injecting this WebResource.axd Javascript file?

Question

When I view source on my ASP.NET page I get the following snippet:

<script type="text/javascript"> 
//<![CDATA[
var theForm = document.forms['form1'];
if (!theForm) {
    theForm = document.form1;
}
function __doPostBack(eventTarget, eventArgument) {
    if (!theForm.onsubmit || (theForm.onsubmit() != false)) {
        theForm.__EVENTTARGET.value = eventTarget;
        theForm.__EVENTARGUMENT.value = eventArgument;
        theForm.submit();
    }
}
//]]>
</script> 

<script src="/WebResource.axd?d=5lheyan7fritNTjDRpG8vA2&amp;t=633734967316503584" type="text/javascript"></script> 

the .aspx file looks kinda like this:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="NaturalDateDemo._Default" %>

<form id="form1" runat="server" enableviewstate="False">
   Enter something to parse:<br />
   <asp:TextBox ID="TextBox1" runat="server" Width="270px"></asp:TextBox>
   <asp:Button ID="Button1" runat="server" Text="Parse" PostBackUrl="Default.aspx" CausesValidation="False" EnableViewState="False" UseSubmitBehavior="true" />
</form>

Both of the chunks of code (the literal code and the stuff in /WebResource.axd) seem to be related to doing JavaScript based post-backs and I can't think of any reason that my page would require JavaScript to do the post-backs.

• What is this doing?
• Where is it coming from?
• Can I get rid of it?
• How can I get rid of it?

The page this question is coming from

---

A little Google work found this indicating that validation controls would cause this, but I don't think I have any validation controls.

Looking at the WebResource.axd file in detail shows a lot of what looks to be boiler plate function that I can't find any references to from anywhere.

---

After further investigation it seem that my submit button is not be doing what I thought it was because it has some JavaScript in its onclick handler. However using FireBug I can see that the page is doing a full refresh (the HTTP response has the full page text) so I have no clue what that's about. OTOH I'm now seeing an __EVENTVALIDATION argument that shouldn't be there (because there is nothing to validate) so that might be interesting to look up.

---

It seems based on the answerer below that what I'm running into is that the default (only?) way for ASP.NET to do a post-back is via JavaScript even when a basic HTML Form would do just fine. (Personally I think this is a stupid design choice on MS part; ASP.NET shouldn't introduce the JavaScript dependency until you ask it to do something that can't be done without it.)

Based on that opinion, several people have speculated that I don't know what I'm talking about. (I will grant that I confused the issue by miss using the term "post-back", thinking it only implies JS based stuff.) While I don't know the implementation details of ASP.NET, I do known how the general HTTP POST stuff works and my opinion is based on considering how I would implement the solution my self and not just based on how I would like it to work.

Answer 1

The answer is a lot simpler than any I've seen here: just remove the PostBackUrl from the Button and all JavaScript disappears like magic.

Without JavaScript, an HTML button cannot submit to another page than the page specified in <form action="...">. However, ASP.NET does provide a possibility to do this out-of-the-box if you specify a PostBackUrl on a Button. That's what the JavaScript is about: supporting a non-default post-back.

In this specific case your PostBackUrl is the same as the <form>'s action, but apparently ASP.NET does not special-case this and any non-empty string triggers this wrapper script.

Answer 2

4 things to check:

1. Are you using an UpdatePanel somewhere on the page?
2. Do you have any javascript making calls to web methods in your code behind?
3. Does your master page have anything in it that might be adding to your output?
4. Are you referencing any controls from an external library?

Once you've investigated that, you might be able to at least cut out some options as to the source of the problem.

Can you provide any sample of the code on your ASPX?

EDIT: Your post now includes a link to the source page. The page has a postback button on the form, which renders results of parsing without doing a full postback (notice that the whole screen doesn't reload). The webresource URL in your path contains the javascript functions used to accomplish this. Your code is doing a partial postback, which is why you have postback-related code on your page.

EDIT #2: To completely remove postbacks from the system, you will need to remove the .NET form submission currently being used by your application. Your button is posting back, therefore it needs code to perform this postback to your server. If you want to remove this, you need to do things with old-school HTML posting straight to another URL. You will need a standard POST form with an action URL and form input fields. However, at that point, you are sort of defeating the purpose of using .NET and its postback support. I guess the final question is why do you need to remove this javascript?

Answer 3

This is how .NET postbacks work, and why a lot of people are moving the the .NET MVC model. In order for the postbacks to work correctly, .NET actually relies on javascript to do a lot of the dirty work. The only way you can really get rid of it is to go with the MVC model.

Answer 4

From looking at your page, I don't understand how you "can't think of any reason that [your] page would require post-backs." It's quite clear to me that when clicking on your Parse button you are calling some methods on the server to interpret the passed in value and convert it to a date, then returning that date to the browser so that the user can see it.

Am I right in assuming that you did not originally create this page and have little experience with ASP.Net? It's not that "MS screwed up big time" (as you mentioned in your comment on Jay S's very well done answer that probably deserves a check mark) it's that your requirements seem to have changed and now you need to ensure that the page works when JavaScript is disabled, which is possible to do with ASP.Net, it's just not the natural way for ASP.Net to do things. However, this will likely require a pretty hefty overhaul of the page, as most drastic changes to requirements do.

Answer 5

If you are using a control that inherits another class, the type passed must be the type of the parent, not the base class