Ajax is a flexible and powerful technology, but sometimes “With great power comes great responsibility” ?. And also some kind of fragility and sensitivity to external factors. In this case browsing the application worked somehow fine, but triggering a partial postback we were getting the following error on the browser: The message received from the server count not be parser. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled. If you get weird Ajax script errors, my experience tell me to always first check if Http compression is enabled on the web server (this is not the first time I tackle this topic), but this was not the case. An important thing to note is that the application was working perfectly fine when browser from the LAN, while it was failing when browsed from the Internet (no matter the browser we were using). An important thing to note is that browsing from the Internet, our request was going through IAG: Intelligent Application Gateway (IAG) is a remote access gateway that boosts productivity by giving mobile and remote workers, partners, and customers easy, flexible, and secure access…
-
-
HoverNodeStyle not applied with partial postback
The TreeView control has built-in Ajax capabilities when it comes to dynamically fill it nodes; this is done through the PopulateNodesFromClient: Sometimes, it is not practical to statically predefine the tree structure due to data size or custom content that depends on user input. Because of this, the TreeView control supports dynamic node population. When the PopulateOnDemand property for a node is set to true, that node gets populated at run time when the node is expanded. In addition to populating nodes on demand, it is possible to populate the nodes directly on a supported client browser. When the PopulateNodesFromClient property is set to true, a service is called from the client to populate the tree nodes, which eliminates the need to post back to the server. Otherwise, the TreeView control posts back to the server to populate the nodes. The EnableClientScript property must also be set to true in order for the PopulateNodesFromClient property to be set to true. Here’s the sample page: Anyway there is a problem: if you run the page you’ll see the ForeColor defined for HoverNodeStyle works as expected (the text turns red) But if you expand one of the nodes clicking on the “+”…
-
WebResource.axd or ScriptResource.axd not working
Http compression with client-side scripting should be handled with care. The problem can have different symptoms and manifest in different ways, but essentially it has a common root cause and I have already discussed some of the aspects (for example see here and here). This time the customer whom reported the problem was using Forms Authentication in his application so the first time an unauthenticated user browsed it, he was redirected to the login page configured in web.config. So far so good. In this case the problem was a javascript error notified by the standard yellow icon in the bottom left corner of IE; the error was an “Object expected” on “WebForm_AutoFocus()” which is a method generated by ASP.NET as a result of an object.SetFocus() call on the server-side. Some quick theory WebResource.axd and ScriptResource.axd are Http Handlers used by ASP.NET and Ajax to add client-side scripting (usually javascript) to the outgoing web page for example to have client-side input validation, set the focus on a specific control (as in this example) etc… Note that if you search your disk for .axd files, you’ll not find them; they are created on the fly in memory and executed from there. Well,…
-
Very slow TreeView in UpdatePanel
This is what we got couple of weeks ago: an Ajax enabled ASP.NET web application was using a TreeView control within an UpdatePanel to show a complex tree of hierarchical data (the sample we got had more than 2.000 nodes with varying degrees of nesting). The result was that browsing the tree within IE was considerably slower if compared with Firefox, about 4 times (where Firefox took 2 seconds to complete the operation, IE took 8 seconds a and sometimes a bit more). With a repro in our hands, a network trace demonstrated that the communication between client and server was working fine (the problem reproduced also on localhost); while having the problem IE was burning a lot of CPU and the relevant thread had a callstack link this: kernel32!TlsGetValue+0xb jscript!GcContext::GetGc+0xc jscript!NameTbl::FBaseThread+0xb jscript!NameTbl::GetVal+0xe jscript!VAR::InvokeByName+0x10d jscript!VAR::InvokeDispName+0x43 jscript!VAR::InvokeByDispID+0xb9 jscript!CScriptRuntime::Run+0x167f jscript!ScrFncObj::Call+0x8d jscript!NameTbl::InvokeInternal+0x40 jscript!VAR::InvokeByDispID+0xfd jscript!VAR::InvokeByName+0x165 jscript!VAR::InvokeDispName+0x43 jscript!VAR::InvokeByDispID+0xb9 jscript!CScriptRuntime::Run+0x167f jscript!ScrFncObj::Call+0x8d jscript!NameTbl::InvokeInternal+0x40 jscript!VAR::InvokeByDispID+0xfd jscript!VAR::InvokeByName+0x165 jscript!VAR::InvokeDispName+0x43 jscript!VAR::InvokeByDispID+0xb9 jscript!CScriptRuntime::Run+0x167f jscript!ScrFncObj::Call+0x8d [...] mshtml!CBase::InvokeEvent+0x1ad mshtml!CBase::FireEvent+0x105 mshtml!CXMLHttpRequest::Fire_onreadystatechange+0x5b mshtml!CXMLHttpRequest::CReadyStateSink::Invoke+0x1d [...] The code behind that was quite simple: protected void onSelectNodeChange(object sender, EventArgs e) { Session["selectedNode"] = TreeView1.SelectedNode.ValuePath; Session["idFirstTree"] = TreeView1.SelectedNode.Value; UpdatePanel2.Update(); } The problem is that the hole tree is destroyed and recreated at every iteration (Sys$WebForms$PageRequestManager$_destroyTree in MicrosoftAjaxWebForms.js); the method traverses…
-
The message received from the server could not be parsed
Again on the Ajax-compression subject (see here and here), here’s another error I got recently: Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled. The customer was using the GZipStream class within an HttpModule to compress the ASP.NET output; everything was working except in pages where he was using some UpdatePanel controls, where he was getting error messages like the above. As you can guess if you’ve read my previous posts, with http compression the response stream was being truncated. There are a couple of solutions available to this error: do not use the HttpModule and rely on IIS compression, or move the application to the .NET Framework 3.5. Remove the HttpModule from web.config Assure ScriptResource is not compressed: <scriptResourceHandler enableCompression=”false” enableCaching=”true” /> Open the IIS Manager Right click on “Web Sites” folder > Properties Click the “Services” tab Check “Compress application files” and “Compress static files” Apply and confirm all dialogs Stop IIS Open a command prompt and go to C:\Inetpub\AdminScripts Run the following commands to add .js, .aspx and .axd to the compression…
-
Ajax resource intermittently not accessible (http compression)
A few days before Christmas I had a case where the customer was intermittently getting troubles with his javascript/Ajax resource; as usual everything was working fine on the development machine, but when moved on the production server the application started throwing some client side javascript exceptions like “myVar is undefined” which means that the Ajax resource was not accessible by the browser. After some of the usual checks and discussions with the customer we found out that the production server was using HTTP Compression which is an old friend of mine (I already rambled about it here); they developed a custom HTTP Module to implement the .NET Framework compression classes and mechanism and disabling it was not an option, since their resource were quite large were affecting the applications’ performance. Then I had a couple of weeks off for Christmas and my colleague Gunnar took over the case (isn’t nice when you go on holiday and someone else takes care of the job for you? ?) and with some further debugging they found this interesting method: private static bool IsCompressionEnabled(HttpContext context) { return ScriptingScriptResourceHandlerSection.ApplicationSettings.EnableCompression && ((context == null) || !context.Request.Browser.IsBrowser("IE") || (context.Request.Browser.MajorVersion > 6)); } This means that Ajax does…
-
Don’t let IE local cache drive you crazy!
I stumbled across this issue multiple times during my life of web developer (which begun about 10 years ago), it appeared every now and then to complicate things when I was in the middle of a heavy debugging sessions and doing frequent changes to my pages; I was expecting some kind of results but despite the fact that the code was looking good, there were no signs of those changes. Sometimes even adding a new UI element like a button or an image or changing the color of a header had no effect… ? Having a look at the page source within IE demonstrated the browser was somehow right not showing the new image or color because it was not there in the code… where was that source coming from? ? Well, if it does not come from the web server, then it’s loaded from the IE local cache… so let’s go to Internet Options > General > Delete > Temporary Internet Files, give it another try and guess what? This time it works…! So, not sure why, but for some reason IE was not refreshing its case and was using an outdated version of my pages. Then after a…
-
Inconsistent Javascript behavior in Internet Explorer
My colleague Stefano had this case a few weeks ago, but since he has not a blog (yet ) and I’ve been partially involved in it, I thought this might be interesting to share… So, here is the story: the customer wanted to disable a button inside the onBlur event of a textbox through client-side Javascript. Reason for this is client-side input data validation: if the user enters some unwanted text, the button must be disabled to prevent him to click it; if the value is then corrected, the button must be re-enabled. The problem is when the textbox has the focus and user presses the button; it will be disabled but it has two side effects: The button stays pressed The page is frozen and when user clicks wherever inside the IE window, it fires the onClick event of the button The source code of the page looked like this: <HTML> <HEAD> <script> function logWriteLine(sText) { log.innerHTML+=sText+"<BR/>"; } </script> </HEAD> <BODY onload='text1.focus();'> <input type=text id=text1 onblur='logWriteLine("text1.onblur called");button1.disabled=true;'/> <BR/><BR/> <button id="button1" onclick='logWriteLine("button1.onclick called");'>button1</button> <BR/><BR/> <SPAN id="log"></SPAN> </BODY> </HTML> I tested this on all of my 3 machines in office and always worked just fine, while Stefano was able to reproduce the problem…