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…
-
HTTP error 406 with .NET Framework 3.0
I got a couple of cases about this problem recently… Imagine this scenario: you install the .NET Framework 3.0 on your client, and then browse an ASP.NET based web site; you get a 406 HTTP return code from the web server, which means “Client browser does not accept the MIME type of the requested page” (see IIS status codes). Uninstalling the .NET Framework 3.0 corrects the problem, and you’re finally able to successfully browse the site. The problem proved itself in two different ways and apparently for two different reasons, but the underlying cause was actually the same. The 406 return code also means that any of the configuration limits has been reached, and digging into IIS logs we found that the problem was actually due to the length of the “Accept” header which has a limit of 256 bytes. Installing the .NET Framework 3.0 you receive support for a few additional file formats, here is how it looks the Accept header on Windows Vista (where the .NET Framework 3.0 is preinstalled): Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-ms-application, application/vnd.ms-xpsdocument, application/xaml+xml, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */* In this case there was a custom ISAPI extension which was actually filtering the…
-
Is your UserControl sluggish at loading?
Here’s an interesting story about performance I had the chance to work on over the last couple of weeks. The object of the call was a UserControl embedded in Internet Explorer, which was very slow to load the first time you browsed the page, but then was performing quite well after that long delay (around 60 seconds); unfortunately closing and reopening the browser caused another 60 seconds delay, which was quite bothering if not frustrating for end users… As you can imagine the control needs to be downloaded, JIT compiled and loaded which of course requires some time depending on how big is the control, how fast (or slow) the Internet connection, how powerful the client etc…, but those 60 seconds where definitely too much. Moreover on Vista we were prompted to run csc.exe and under some circumstances (usually if IE was not run as Administrator) we got a FileNotFoundException. Probing First thing, Fiddler showed that after downloading the first dll (the actual UserControl) we were probing for further localized resources, so we wasting about 15 seconds just for this reason (which is a quarter of the entire time spent waiting on a white IE page…). At the same time…
-
Debugger not debugging, and Response.Redirect() not redirecting…
The customer was working on a WinXP machine joined to a domain, but had logged in using a local account (I’ve not tested if this may have contributed to the problem so this may be a useless information). Anyway to make things easy I connected to the faulting machine using EasyAssist to have a better look at the configuration: everything looked fine both in IIS and Visual Studio. Interestingly browsing the application from IE directly we found that even if he was using “http://localhost/app” the page was shown in the “Internet” zone (hence the debugger error). This usually happens when the application is created using either the IP address or the FQDN (Fully Qualified Domain Name) of the web server; to verify, we created a new test project as “http://localhost/test” but got the same debugging problem, and again the page belongs to the Internet zone. As a test we enabled “Automatic logon with current username and password” for the Internet zone and then the debugging started working fine. Talking about this with my team colleagues they suggested uncheck “Automatically detect intranet network” in the “Local Intranet” settings and enable the three remaining checkboxes; this because under some circumstances IE may…
-
Avoid UAC prompt in IE component
Wow, this has been a tough one I closed this afternoon. The customer has developed a custom IE toolbar to interact with their portal, and found that when running this on Vista, IE displayed a warning dialog asking the user’s consent to run an external program; in particular that was happening when the toolbar was calling a Web Service to retrieve some content from the web server. If for test we denied the permission to run the external problem, we got this error message: “System.Runtime.InteropServices.ExternalException: Cannot execute a program. The command being executed was “C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe” /noconfig /fullpaths @”C:\Users\Vista\AppData\Local\Temp\Low\ev4a0rzg.cmdline“.” The exception occurred when the SOAP client proxy tries to spawn the compiler to generate the type serialization assemblies the first time the web service is called. After the usual log analysis we setup a repro in a virtual machine, and we found that this was not an UAC issue but rather an IE Protected Mode problem (by the way, Protected Mode in IE is currently available only on Vista, so maybe this is why the customer thought to this as an UAC issue); this was confirmed by turning off Protected Mode for a test, and the prompt to the user disappeared.…
-
Broken line in ASP.NET 2.0 TreeView in IE 7
Create a very simple page in ASP.NET 2.0, add a TreeView control and set ShowLines=true; now browse the page with Internet Explorer 7: you’ll very likely see something like this: In IE 6 this looks good… 🤔 The point is that Internet Explorer 7 changes the boxing model: now a box that’s too small to accomodate ita content won’t stretch like it does on all other browsers including IE6, it will try to stay as small as possible. The problem in this case is that the DIV tags generated by the control are just 1 pixel height, which was working fine until now. Here is how the “View source” for the page above looks: 1: [...] 2: <table cellpadding="0" cellspacing="0" style="border-width:0;"> 3: <tr> 4: <td> 5: <div style="width:20px;height:1px"> 6: <img src="/TreeViewSample/WebResource.axd?d=vGK_uMmdWLf5UZMMUhv9tSAl-YQg-jrsZ90xzYAI6TE1&t=632985107273882115" alt="" /> 7: </div> 8: </td> 9: <td> 10: <a id="TreeView1n1" href="javascript:TreeView_ToggleNode(TreeView1_Data,1,TreeView1n1,'l',TreeView1n1Nodes)"> 11: <img src="/TreeViewSample/WebResource.axd?d=vGK_uMmdWLf5UZMMUhv9tfjlKbdZ_ojL4O8CY0ydKO_HFK9lO1t2cZ2AjaDIqJy_0&t=632985107273882115" 12: alt="Collapse New Node" style="border-width:0;" /> 13: </a> 14: </td> 15: <td style="white-space:nowrap;"> 16: <a class="TreeView1_0" href="javascript:__doPostBack('TreeView1','sNew Node\\New Node')" 17: onclick="TreeView_SelectNode(TreeView1_Data, this,'TreeView1t1');" id="TreeView1t1">New Node</a> 18: </td> 19: </tr> 20: [...] As you can see, the first DIV tag contains a style definition with “height:1px”; that’s the problem. And now, here is how we can…
-
ASP.NET 2.0 application running in Firefox and not running in IE
Every now and then we get calls from a customer who decided to migrate his application from ASP.NET 1.1 to 2.0 (and sometimes those are mission-critical ones…) just changing the relevant mappings in IIS console, to then discover that the application is no longer working, or has some quite weird behavior which gives them headaches… Luckily that was not the case of the call I’ll now talk about; to test if the application could work against ASP.NET 2.0 the customer made the very quick test described above: they simply changed the mappings through IIS console and immediately notice that something was going wrong inside the app. They started troubleshooting the problem themselves and have then been able to repro the same problematic behavior inside a minimized application, just a simple .aspx page with some very basics functionalities in there (just a page with a command button and a GridView to fill with some data coming from Sql Server). This minimized repro was working fine on the dev machine with Cassini, but once installed in the target web server (Windows 2003 with IIS 6.0); when browsing with IE, the resulting HTML lacks completely the client-side Javascript to trigger the postback (while…
-
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…
-
Integrated Authentication does not work with domain name
This is an easy one, but we got cases like this every now and then… maybe worth repeating. If you use Windows Integrated Authentication in IIS, everything works fine if you browse “http://netbiosname”, but Integrated Authentication fails is you browse “http://dnsname”. Why? Because if the DNS machine name contains a dot (“.”), the web site automatically belongs to the “Internet” zone, and by default IE does not sent the account credentials. How to solve this? Easy, you have two options: Add the URL to the “Trusted Sites” in Internet Explorer Modify the security parameter to allow “Automatic logon with current user name and password” (Control Panel -> Internet Options -> Security tab -> Internet -> Custom level…) Update: By the way, I forgot to mention that this is also true if you use the IP address instead of the netbios name: e.g. http://xxx.xxx.xxx.xxx Cheers