On a search form with only one search term box and one submit button, such as the Quick Search form in the Andornot Starter Kit, the usual user behaviour is to type search terms and press the Enter key. However, there is a longstanding issue with ASP .NET that results in seemingly nothing happening in this case, in some browsers. The form does a weird empty postback because it submits the form, but does not call your ASP.NET submit button's click event: i.e., it does a postback, but does not do anything. The user must instead use the mouse to click the Submit button.

A simple workaround for this is to add a second search box to the form, but make it invisible. For example, add:

<input type="text" style="display:none;" />

Now when the user presses the enter key, the subsequent postback operates as expected (i.e. in the case of the Andornot Starter Kit Quick Search form, it submits the search instead of just doing an "empty" postback that doesn't do anything).

More information on this ASP.NET behaviour is available here. Information on similar behaviour in AJAX Update Panels is in an earlier Andornot developer blog post.

Using ASP.NET AJAX extensively in my latest project I've been sporadically running into the Sys.WebForms.PageRequestManagerParserErrorException. It got to the point that I was contemplating ripping out ASP.NET AJAX completely until this known issue had been ironed out. The various causes for this error are mentioned many different places, but for some samples, go here, here, and here.

Quoting from Eilon Lipton's blog posting, this particular exception is very common and can be caused by any one of the following:

1. Calls to Response.Write():
   By calling Response.Write() directly you are bypassing the normal rendering mechanism of ASP.NET controls. The bits you write are going straight out to the client without further processing (well, mostly...). This means that UpdatePanel can't encode the data in its special format.
2. Response filters:
   Similar to Response.Write(), response filters can change the rendering in such a way that the UpdatePanel won't know.
3. HttpModules:
   Again, the same deal as Response.Write() and response filters.
4. Server trace is enabled:
   If I were going to implement trace again, I'd do it differently. Trace is effectively written out using Response.Write(), and as such messes up the special format that we use for UpdatePanel.
5. Calls to Server.Transfer():
   Unfortunately, there's no way to detect that Server.Transfer() was called. This means that UpdatePanel can't do anything intelligent when someone calls Server.Transfer(). The response sent back to the client is the HTML markup from the page to which you transferred. Since its HTML and not the special format, it can't be parsed, and you get the error.

The problem was I wasn't doing any of the above (who uses Response.Write in an ASP.NET application these days?) and I was still sporadically encountering the error - a show stopping error I might add. An error that is popped up in a javascript warning box completely undecipherable to the end user leaving an empty/useless/castrated UpdatePanel in its wake. This of course leaves the end user feeling likewise empty/useless/castrated (to say nothing of the developer).

This post here indicates that there is a problem with the RoleMangerModule or any time you set a cookie to the response in an AJAX callback, which can only be solved by doing one of the following:

1. Disable caching of cookies in the RoleManager. (yuck)
2. Handle the Application's Error event to clear the error from the Context selectively (eek).
3. Disable EventValidation in the web form.
   <%@ Page Language="C#" EnableEventValidation="false" %>
   (gulp)

None of the above are entirely reasonable solutions (especially the last two), and the worst part was that my test page was just a simple contact page that did not change/set roles or cookies, or response.write, or set anything in the session, and wasn't receiving any Unicode character input, or even requiring a user to be logged in, or writing anything to the trace, or anything beyond the basics. And still it blew up. But only occasionally.

In order to faithfully reproduce the error, I finally determined that it must have something to do with sessions as it would only occur if the app pool had recycled and all browser windows had been closed. So, based on one of the comments in one of the above posts, even though I'm not touching session on one of the problem pages, I tried a hack in one of the problem page's Page_Load:

Session["FixAJAXSysBug"] = true;

And lo and behold, we're good to go! So even though I am not using Session on the problem page it must be attempting to set the initial session cookie using the Update Panel callback. So the solution is to make sure the initial session is set before any Update Panel callback takes place. How this got through into production is beyond me.

So if you're sporadically encountering the Sys.Webforms.PageRequestManagerServerErrorException, it could be for any of the above reasons or the fact that your dog/cat/stuffed teddy bear is sitting too close to your monitor. But give the last one a try in every page utilizing AJAX if you're using sessions in your application.

UPDATE: If the problem pages aren't even using session, just turn session off for the page:

<%@ Page EnableSessionState="false" ... %>

Or better yet, set it in your base class to always be off, and turn it on for the pages where you need it on.

UPDATE II: Further developments.

ASP.NET AJAX (code-name "Atlas") v1.0 was released in full yesterday. It's exciting stuff, even if it's yet another package to swallow and digest on top of all the other innovations that have come flying thick and fast this past year. It can get disorienting, to be honest. Probably my age catching up with me - I'm no spring chicken. More of a late summer chicken. It's a good thing I learn fast. (Kids! If you come out of school having learned nothing else but how to learn, you're all good! Xcpt yor eng skiLz suk!)

The fun part is looking at the candy in the AJAX Control Toolkit. Like touring Willy Wonka's Chocolate Factory, and I'm Augustus Gloop.

Some major additions to the Ajax Index Popups:

• Now usable for validation lists
• Entry separator now a parameter
• Other fields now a parameter
• Options to avoid putting plaintext passwords in the query string

Validation List Browsing Same features as index browsing, including paging, find-as-you-type, selection builder, etc. Scales up to even very large enormous big big validation lists. Entry Separator Parameter Particularly useful for picking from validation lists. Defaults to bullet (·) but can be overriden depending on the environment. (Genie entry separator is different than ordinary WebPublisher, which is different again from Inmagic ODBC.) Other Fields Parameter I don't know why I didn't add this in the first place. Other fields can be chosen for browsing by the user once the index popup has loaded. No, the field lists aren't merged. But a plus is that alternative labels can be identified for these other fields. E.g. you have a field named "ugly_fld_name", but can have it display as "Gorgeous Field". Password Options Passwords can be passed in plaintext with the query string to the index popup, or a single "master" password can be set in the config file to be used every time, or password 'translations' can be set in the config file - i.e. when query string password=pass1, use "mypassword" as the real password. This means you do not have to let your actual textbase-level passwords be viewable in your HTML. Of course, any sniffer would be able to get the real password from the HTTP request, but at least your page visitors won't easily be able to read the password by going to "view source".

AJAX-enabled Index Popups for Inmagic DB/WebPublisher Pro and CS/Webpublisher Pro are ready to go. Late feature additions:

• Entries show full value in tooltip if hovered over (helps when long entries are cut off)
• Entries are flagged onmouseover to guide the eye
• Paging buttons look disabled when they are disabled
• Scroll bar visible when needed, invisible when not - depends on page size.
• Better x-browser support. Mac IE5.2 still eludes me - it's as brainless as ever.
• Help button shows help text on mouseover. Help text can be edited.
• Close window link at bottom of window.

See Demo.