Fix: CSS border-radius not working in Internet Explorer 11

In doing browser compatibility testing in a new web form I was developing on my PC this morning, the form looked great in all browsers I had on my local Windows 8.1 PC – except for Internet Explorer 11, where it looked awful: div and form field border corners were squared instead of rounded, form fields rendered with excess height, some text was slightly truncated, and a few other issues.

When I looked at the CSS styles in use on the page in IE11’s built-in F12 developer tools, I noticed that the border-radius property on my form’s enclosing div was present, but it was missing its enable/disable checkbox, and the name of the style was shown with a red squiggle underline, as though IE didn’t recognize it.  It seemed almost as though IE11 was behaving like a legacy browser that didn’t recognize that newer CSS property.

In fact, that did turn out to be exactly the problem. IE11 was rendering the form (running on my local IIS) with its legacy “Compatibility View” engine, which it is by default configured to do for intranet sites.  (Oddly, my IE11 was not using Compatibility View to render another copy of the form that I was trying to use to debug the issue that I had IE loading via the “localhost” domain, which had me confused for a while.)

The solution was to disable IE11’s Compatibility View for intranet sites by doing Setting (gear icon) > Compatibility View Settings > uncheck “Display intranet sites in Compatibility View” checkbox.  Making that configuration change immediately got IE11 to start rendering the page properly.

Chrome Browser Deal-Breaker: Ctrl+Tab behavior

Depending on who you ask, Google Chrome is the world’s most popular browser here in mid-2012.  It’s fast, lightweight, and standards-compliant.  However, Chrome has one major (for me) issue that will prevent me from ever using it as my primary browser: The lack of any way to modify the behavior of the Ctrl+Tab keyboard shortcut to switch between tabs.

Like the other leading desktop web browsers Firefox and Internet Explorer, the default behavior of the Ctrl+Tab keyboard shortcut in Chrome is to switch between tabs in left-to-right order.  I’ve believed for years that this behavior is inefficient at best, and the default switch order for Ctrl+Tab should be most-recently-used (MRU) order. The default left-to-right Ctrl+Tab switch order makes it impossible to quickly use the keyboard to toggle back and forth between two tabs when there are multiple tabs open.  Left-to-right order is also inconsistent with the long-established MRU order for the keyboard shortcut for switching between open applications (Alt+Tab in Windows and many Linux distributions; Command+Tab in OSX).

Unlike Firefox and Internet Explorer, however, Chrome offers no way to change the default Ctrl+Tab behavior, even via add-ons / extensions.  To compare the three leading desktop browsers:

• Firefox: Has an excellent addon called LastTab which has a great implementation of MRU Ctrl+Tab behavior (including an Alt+Tab-like preview window of the tabs arranged in MRU order);
• Internet Explorer: Has a “Use most recent order when switching tabs with Ctrl+Tab” checkbox in its Advanced Options settings;
• Chrome: There’s no configuration setting to change the Ctrl+Tab behavior.  The Ctrl+Tab key combination apparently is defined as “reserved,” so extensions can’t change its behavior either.

There’s a long-standing (2008) Chromium bug, Issue 5569, logged for Chrome’s Ctrl+Tab behavior; however, it was marked as “WontFix” shortly after it was opened.  Google does acknowledge the demand for MRU switching behavior in a brief statement on the Chromium project’s User Experience > Tabs page:

Ctrl+Tab, Ctrl+Shift+Tab, Ctrl+PgUp and Ctrl+PgDn can all be used to switch back and forth between tabs. While there is great demand for an MRU-ordered switcher, we've so far been unable to find an MRU switcher that makes sense beyond the first three most recent tabs, or one that works well with background-created tabs.

I’m somewhat bemused by this statement; there are many good reference implementations of MRU switching order available.  One specific example is the LastTab Firefox extension mentioned above; I’ve used that for years and have been very happy with it.

If you’d like to add your vote to this issue, feel free to head over to Chromium Issue 5569 and “star” the issue and/or leave a comment.

This issue is a deal-breaker for me to consider adopting Chrome as my primary desktop web browser – Chrome’s benefits don’t outweigh the potential several-times-per-day productivity hit of not being able to rapidly and easily toggle between two specific browser tabs.  In the meantime, I’m happy to continue using Firefox as my own primary browser. 

In occasional situations where I do need to use Chrome and have multiple web pages open, going old school and opening each web page in its own browser window (instead of using multiple tabs) is a tolerable workaround (since that lets me use the operating system’s MRU window switching behavior to rapidly toggle back and forth between two windows as needed).

Windows Forms Controls in IE Troubleshooting Guide

This post covers troubleshooting information for issues with loading .Net Windows Forms Usercontrols in Internet Explorer. IE in many cases does not provide clear error reporting when something goes wrong with loading a Windows Forms control embedded in a web page; the information here is presented to hopefully act as an aid in troubleshooting such issues.

For information on the general technique of embedding Windows Forms controls in web pages via <object> tags for viewing in Internet Explorer, take a look at these tutorials:

• Using Windows Forms Controls in Internet Explorer (WindowsForms.net) (Update 11/17/2008: Fixed this link, which had become broken on Microsoft's end.)
• Host Secure, Lightweight Client-Side Controls in Microsoft Internet Explorer (MSDN Magazine)

Tip: Viewing Fusion Bind errors from Internet Explorer

When a Windows Forms control fails to initially load properly, one or more "fusion bind errors" with information that may be helpful in diagnosing the problem may be logged.

Viewing fusion bind errors generated from errors loading .Net controls in Internet Explorer:

• Open the Temporary Internet Files folder in an Explorer window. (One way to do this is from Internet Explorer, select Tools | Options; on the Internet Options dialog, on the General tab, next to "Browsing History", click Settings; on the Temporary Internet Files and History Settings dialog, click "View files".)
• In the Temporary Internet Files explorer folder, sort by the Last Modified column to bring recent fusion bind error files to the top.
• Look for files named "?FusionBindError ...". You can't double-click these files to view them; instead, open a new Internet Explorer window, and drag one of the Fusion Bind Error files to the new window to view the contents.

Setting up .Net framework trust to allow Windows Forms controls hosted in a web page on a remote web server to run

For .Net controls embedded in web pages that perform certain types of operations, .Net framework code access security trust must be set up to allow the control to load and run; if this is not done, the security policy of the .Net framework on the client machine will prevent the control from loading.

If a .Net control does fail to load due to load due to .Net trust not being set up properly, the symptom will be an empty rectangle with a "colorful icon" present in the top-left corner displayed on the web page in place of the control. (See the FAQ section below.)

In an internal corporate / LAN environment, trust can be granted to the web server hosting the web page that includes the .Net control. This can be done from the client machine by using the Microsoft .Net Framework Configuration tool (if it is installed), or from the command line by using the caspol.exe utility.

Granting .Net trust to a specific web server with the Microsoft .Net Framework Configuration tool

This tool is not installed on all machines. (I'm not sure when/how the tool does get installed on machines where it is present.) On machines where the tool is present, it can be found in the Administrative Tools folder as "Microsoft .NET 2.0 Configuration", where "2.0" is the actual installed version of the .Net framework.

Be sure to set up trust using the version of the tool that matches the .Net version which Internet Explorer will be using to load and run .Net controls. (In most cases, this will be newest version of the .Net framework installed on the machine.)

Setting up .Net framework trust on a single client machine for controls running on a particular web server:

• Drill to .NET Framework Configuration | My Computer | Runtime Security Policy | Machine | Code Groups | All_Code.
• Right-click All_Code and choose New from the context menu.
• In the Create Code Group dialog that appears, enter a name for the new code group, then click Next. (The name can be anything, but I suggest using the name of the web server machine for which trust is to be established.)
• In step 2 ("Choose a condition type"), select URL from the dropdown; in the URL field that appears, enter "http://mywebserver/*", where mywebserver is the actual name of the web server to trust. (If you use SSL to connect to the web server, enter "https" instead of "http".)
• In step 3 ("Assign a Permission Set to the Code Group"), check the "Use existing permission set" radio button and select "FullTrust" from the dropdown. Click Next.
• Click Finish on the final step of the Wizard.

Granting .Net trust to a specific web server with the caspol.exe command-line utility

Caspol.exe is a command-line code access security policy tool that is installed with the .Net framework. Caspol.exe is located at:

%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\caspol.exe

Where 2.0.50727 is the version number of the .Net framework installed on the client machine that IE is using to load the control. (2.0.50727 is the version number of the commercial release of the 2.0 .Net framework.)

Run the following command to establish .Net framework trust for a web server named serverName:

caspol -machine -addgroup 1 -url http://serverName/* FullTrust -name "http://serverName"

To view existing trust group settings set up on the local client machine, use:

caspol -lg

Regardless of which method is used to establish trust, after setting up trust for the web server, you'll need to close and re-open Internet Explorer to get it to pick up new trust setting.

The remainder of this document takes a FAQ format, with problems/issues in boldface and possible resolutions in plain type.

The "Colorful Icon" Issue

When attempting to load a Windows Forms control, the control does not appear; instead, a white box with a thin black outline appears in place of the control, with a colorful icon in the top-left corner.

A Windows Forms control that has failed to load, showing the "colorful icon"

Q: A Fusion Bind error is logged with this text: "System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Security.VerificationException: Operation could destabilize the runtime."

A: The most common cause of this problem is that the control requires .Net Framework trust to run, but trust has not been granted to the server hosting the control, or to the control itself, by the client machine (the computer where Internet Explorer is running). See "Setting up .Net framework trust" above.

Other general things to check for a control failing to load with the "colorful icon" symptom:

A: The client machine might be configured to not trust unsigned .Net or ActiveX controls in IE | Tools menu | Internet Options | Security tab. (Not sure about the exact setting.) Adding the web server to "Trusted Sites" on the client will generally fix this. (This seems particularly common when the client is Windows 2003 Server.)

A: If the class constructor of the .Net control is throwing an uncaught exception, this behavior will occur. Try stepping through the constructor in a debugger (assuming the control is one you are developing).

A: Try clearing the Temporary Internet Files on the client machine (especially if some .Net components in the browser are working, but not others).

A: If the same browser window was previously used to bring up the same .Net control from a different virtual directory on the server machine, close the browser window and use a new one.

A: There could be something invalid or malformed in the client machine's machine.config file.

A: There could be an invalid or malformed iexplore.exe.config file present in the same folder as the Internet Explorer executable (typically C:\Program Files\Internet Explorer\). Try temporarily renaming the iexplore.exe.config file to something else.

More specific symptoms and resolutions for situations where IE is showing the "colorful icon" in place of the .Net control after the control has failed to load:

Q: Client is connecting to server using SSL (https://...). Connecting to the server using a normal (non-SSL, http://...) connection does load controls correctly (if the server permits non-SSL connections).

A: Ensure that .Net framework trust is set up on the client machine for the web server machine with both the "https://" and "http://" prefixes (2 separate trust entries).

A: In Internet Explorer | Tools | Options | Advanced tab, uncheck "Do not save encrypted pages to disk".

Q: On the server machine, the most recent event in the IIS log is a 401 error trying to load a config file linked from the web page where the .Net control is located using a <LINK REL='Configuration' HREF='/configFile.conf'> tag. No Fusion Bind error is logged on the client.

A: Check the Windows filesystem permissions on the .conf file. Try giving the "Everyone" group full permissions on the file to establish whether or not this is the problem. (If applying "Everyone" permissions does work to resolve the issue, you will probably then wish to remove "Everyone," and apply more fine-grained permissions, to allow IIS to serve the control, but without compromising security.)

A: On the server, in IIS Manager, under File Security for the config file (for that specific file, not the parent virtual directory security), if Anonymous access is checked, ensure that "Allow IIS to control password" is also checked.

Q: Server OS is Windows 2003 Server. Navigating in the browser directly to the config file referenced in the .Net control's web page results in a 404 error (even though the file really is there on the server).

A: In the Internet Information Services Manager utility, open the Properties dialog for the config file's parent virtual directory. In the HTTP Headers tab, click the Mime Types... button, and add the config file's extension (.conf).

Q: A new .Net framework version was recently installed on the client, after which the control started failing to load.

A: Set up trust for the web server machine under the new .Net framework version (as described above).

Q: A Fusion Bind error shows a FileLoadException and error message text that talks about a DLL file version incompatibility. The control may load properly from a different client machine, or when a different user is logged into the OS.

A: Clear the Shadow Cache for the user on the machine where the problem is occurring. (The Shadow Cache is typically located at "C:\Documents and Settings\username\Local Settings\Application Data\assembly\dl?", where ? is a numeral. Delete the entire directory tree under the "dl?" folder to clear the cache. It may be necessary to enable viewing of hidden files/folders to see the cache.)

Q: When using compressed .cab files referenced from a .conf file on the server to deliver the .dll file(s) for the Windows Forms control, a fusion bind error shows "System.IO.FileNotFoundException: File or assembly name ControlType, or one of its dependencies, was not found.

A: This may indicate some problem on the server or client with loading .cab files. One possible cause: The MIME type associated with cabinet files (.cab) is incorrectly set in IIS (HTTP Headers | File Types) to a content type of "application/x-compressed"; the MIME type associated with a .cab file must be "application/octet-stream" for .Net to load the controls from the cab file. In inetmgr, in the HTTP headers tab, click File Types... and fix the setting.

Q: The Fusion Bind Error shows something like "System.TypeLoadException: Could not load type 'Typename' from assembly 'TypeName'"

A: The class name specified in the object tag needs to have correct casing (uppercase/lowercase). In the example above, you would need to change "Typename" to "TypeName".

"Vertical Scrollbar" issues

Q: When attempting to load a Windows Forms control, the control does not appear; instead, a white box with a thin black outline appears in place of the control, with a colorful icon in the top-left corner.

A Windows Forms control that has failed to load, showing the "disabled vertical scrollbar"

A: Check the classid parameter of the control's <object> tag to be sure it is pointing at a valid virtual directory.

A: Make sure that the DLL file referenced in the classid is present in the virtual directory.

A: Rarely, I've seen this issue happen when in on the server, IIS settings (inetmgr), Execute Permissions for the virtual directory is set to "Scripts and Executables". Try setting Execute Permissions to "Scripts only".

A: When debugging an ASP.NET page through Visual Studio 2005, apparently the "ASP.NET Development Server" that Visual Studio 2005 provides for debugging ASP.NET 2.0 apps doesn't support display of Windows Forms controls in the browser. Use the real IIS server on the machine instead. (You can debug the ASP.NET page running in IIS by manually attaching the Visual Studio debugger to the aspnet_wp.exe process once the ASP.NET site has been initially opened in the browser.)

"X" Icon Issues

Q: When attempting to load a .Net control, the control does not appear; instead, a white box with a thin black outline appears in place of the control, with an "X" icon in the top-left corner.

A Windows Forms control that has failed to load, showing the "X" icon

A: Make sure that the .Net framework has been installed on the client machine.

A: Check that a classid parameter is present in the <object> tag in the HTML source of the web page where the control is located.

A: Check the primary DLL file of the assembly that the control is attempting to load. (I've seen this happen in a contrived case when a control was trying to use a .dll file with file size 0.)

Other Issues

Q: When attempting to load a .Net control, an error dialog appears: "Your current security settings prohibit running ActiveX controls on this page. As a result, the page may not display correctly." After the dialog is dismissed, the control does not appear on the page at all.

A: In Internet Explorer, go to Tools | Internet Options | Security tab. Running signed ActiveX controls needs to be allowed for the "zone" that the web server is in; the zone settings can be changed to "Medium", or the web server can be added to a more trusted zone ("Local intranet" or "Trusted sites").

Q: After a .Net control loads, it appears correctly, but the user needs to click the control before it can be interacted with. Before the control is "activated", a tooltip appears when the mouse is hovered over the control with text "Press SPACEBAR or ENTER to activate and use this control" or text "Click to activate and use this control".

A: This issue is caused by a change that Microsoft was forced to introduce in Internet Explorer due to patent litigation between Microsoft and Eolas. For details and workarounds, see the article Activating ActiveX Controls on MSDN.

Q: When attempting to load a .Net control, the control does not appear; instead, a solid gray box with no error message text appears.

A: Check the syntax of the <object> tag in the HTML source. IE is probably not recognizing it as an attempt to show a Windows Forms control.

Scripting Issues

Q: When calling a public API method on a .Net control from Javascript running on the web page, the Javascript error "Object doesn't support this property or method" occurs.

A: The .Net control probably didn't load successfully. (This may be non-obvious if the control is hidden on the page.)

Q: A script call to a .Net control fails with the Javascript error message "Unexpected call to method or property access."

A: Apparently IE doesn't support child windows directly calling methods in Windows Forms controls located in a browser parent window (using syntax like "window.opener.document.ControlID.Method()") . As a workaround, rewrite the script to call a Javascript function on the parent page, then have the new function make the actual call to the .Net control.

Q: A script call to a .Net control fails with the Javascript error message "Invalid procedure call or argument."

A: The script code may be calling the method with an incorrect number of method parameters.

Debugging Issues

Q: After making a code change to the .Net Usercontrol and rebuilding, the changes made are not reflected in the browser window, even after refreshing the page.

A: Close the current browser window, and reopen the web page in a new one.

Q: Can't hit breakpoints in the Visual Studio debugger when debugging a .NET Windows Forms object in the browser.

A: If launching the browser directly from Visual Studio, in Project Properties, on the Debug tab, make sure "Start external program" (pointing to iexplore.exe) is checked, not "Start browser with URL".

A: Make sure the DLL files used in the page being debugged are debug (not release) versions.

Q: When the Visual Studio 2003 .Net debugger is attached to an iexplore.exe instance, as soon as a .Net control starts loading, the browser closes and debugging ends. Both .Net 1.1 and 2.0 (or a later version) are installed on the machine. Q: Can't attach the VS.NET 2003 debugger to an iexplore.exe instance which is already running a .NET control.

A: Visual Studio 2003 can only debug .Net version 1.1 (not 2.0 or later versions), so you need to force IE to load controls using the 1.1 .Net framework. Create a new file named iexplore.exe.config in the Internet Explorer folder (the folder where iexplore.exe is located) with the following content:

<configuration>
 <startup>
   <requiredRuntime version="v1.1.4322"/>
   <supportedRuntime version="v1.1.4322"/>
 </startup>
</configuration>

This will force Internet Explorer to load any .Net controls that it encounters in web pages in the 1.1 version of the .Net framework, beginning with the next time a fresh instance of Internet Explorer is opened.

When finished debugging in Visual Studio .Net 2003, remove the iexplore.exe.config file to permit .Net controls (and possibly also Internet Explorer extensions) which require .Net 2.0 to run properly once again.

The information in this post is current as of Internet Explorer 7 and the .Net framework 2.0.

Please note that this is not a comprehensive guide to all possible issues that may occur with running .Net Usercontrols in Internet Explorer; also, the troubleshooting suggestions here may not work to resolve a given issue in all cases. Please use caution when making configuration changes to your system (particularly security-related changes)!

Strict mode IE6 bug with CSS "Bottom" style on img tags

While working on part of a new ASP.Net site at work recently, I came across a weird behavior when viewing the page in Internet Explorer 6 where a particular image on the page wasn't staying aligned with the surrounding elements on the page when the browser window was resized. I was able to boil the problem down to a very simple repro case on a basic html page. Here's the source code for the repro page:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
 "http://www.w3.org/TR/html4/strict.dtd">
<html>
<body>
  <img src="AnyKey.gif" style="position:absolute;bottom:20px">
</body>
</html>

It turns out that the problem is that for whatever reason, IE6 only recalculates the position of the image relative to the bottom of the browser window when the browser window is resized horizontally -- but not when the browser window is resized vertically! So on IE6, if you resize the browser window to be vertically, the image stays fixed in place, not moving to follow the bottom edge of the window. But when you resize the browser window horizontally, the image immediately pops back into its proper place relative to the bottom edge of the window.

I went ahead and put the repro page up on my website, here -- feel free to take a look if you happen to be using IE6.

Oddly enough, this issue only affects IE6 when in CSS standards-compliance mode; if the page is put into the IE6 quirks mode by deleting the !DOCTYPE tag from the top of the html source, the image does correctly move to follow the bottom edge of the browser window when the window is resized vertically in IE6.

The workaround I found for this issue is simple; just enclose the img tag in a div tag, and put the style attribute on the div tag instead of the img tag:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
 "http://www.w3.org/TR/html4/strict.dtd">
<html>
<body>
  <div style="position:absolute;bottom:20px">
    <img src="AnyKey.gif">
  </div>
</body>
</html>

This odd behavior doesn't happen in the other browsers I tested (IE7 and Firefox 2.0).

I am looking forward to the day when IE6 has been phased out enough that needing to code around its occasional quirky behavior is no longer necessary -- but that day is most likely years away yet!

Possible fix: IE7 won't show Favicon

I ran into a problem this morning where my install of Internet Explorer 7 was refusing to show the new favicon that I had dropped into the root directory of the website on my local IIS 5 installation for web pages hosted on the server. (Previously, the site had been running without any favicon.)

(A "favicon" is the icon image that gets displayed in the browser's address bar and as the bookmark icon, among other places, for websites that are designed to take advantage of that functionality. For example, the University of Michigan site uses a maize-and-blue "M" icon as the favicon. Note that in IE6, you need to bookmark a site and load that site back from the bookmark before the favicon will display in the address bar.)

Although all the reading I had done suggested that IE7 has full support for favicons, the new icon wasn't being displayed for any of the pages on my site; IE7 would instead just show the generic "IE document" icon. The icon did display correctly in Firefox, and also in another copy of IE on a different machine. Looking at the web server's IIS log, I could see that IE7 wasn't even attempting to request the favicon.ico file from the server.

I tried some simple workarounds to try and trigger IE7 to request the new icon, such as clearing IE's temporary internet files and re-bookmarking the web site, but didn't have any luck. And I could see that my IE7's support for favicons wasn't totally broken, as other sites in my bookmarks (favorites) list did still correctly display their favicons.

After spending a fair amount of time researching the problem across various websites and newsgroup postings, I finally came across a suggested workaround/solution at Wickham's XHTML & CSS tutorial (thanks Wickham!) that ended up fixing the problem for me. The workaround was to clear my IE7 browsing history. (Ctrl+H to bring up the History panel, then select each of the top-level items and delete them with the Delete key).

After clearing my IE history and closing and reopening the browser window, the favicon finally did display properly.

I'm unable to reproduce the issue now; my copy of IE7 is now correctly immediately picking up changes when I remove the favicon.ico file or drop a different favicon.ico into place, so I can't be certain that deleting the IE7 history (which admittedly seems like an odd solution) was what actually fixed the problem. Still, I'm posting this here in hopes that the workaround of clearing IE7's browsing history might be helpful to anyone else who is having a similar problem getting IE7 to properly show a particular website's favicon.

Update 3/7/2007: Jeff Davis ("jeffdav") from the Microsoft Internet Explorer team has posted to his blog a troubleshooting guide for favicons in IE7. It actually does mention clearing browsing history as a possible fix for favicons not showing up as expected. Go check it out if you're having trouble with favicons in IE7! (Thanks for the info, Jeff!)

Windows Forms in IE don't load properly in ASP.NET AJAX 1.0

I'm currently running into a problem where Windows Forms .NET controls embedded in a web page, when included in an ASP.NET AJAX UpdatePanel, fail to load properly after the UpdatePanel is updated. An "x" icon is displayed where the control should be.

For a simple UserControl that would normally appear like this:

This is displayed instead after the AJAX update:

Unfortunately, I haven't been able to figure out the root cause of this issue yet. I took a look at the post-update HTML (using a trick from Rumen Stankov -- thanks Rumen!) generated by ASP.NET AJAX, and the HTML looks to be ok.

The problem can be reproduced using a simple .aspx page:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
 <title>ASP.NET AJAX and Windows Forms</title>
</head>
<body>
 <form id="form1" runat="server">
   <asp:ScriptManager ID="ScriptManager1" runat="server" />
   <asp:UpdatePanel ID="_gaugesUpdatePanel" UpdateMode="Conditional" runat="server" >
     <Triggers>
       <asp:AsyncPostBackTrigger ControlID="_updateButton" />
     </Triggers>
     <ContentTemplate>
       <object id="TestControl" name="TestControl"
         classid="TestControl.dll#TestControl.SimpleUserControl"
         height="100" width="200">
       </object>
     </ContentTemplate>
   </asp:UpdatePanel>
   <asp:Button ID="_updateButton" Text="Update" runat="server" />
 </form>
</body>
</html>

When this page initially loads, the Windows Forms control displays correctly. After the "Update" button is clicked (triggering the UpdatePanel to be updated), the control fails to load and the "x" icon is displayed.

For this sample, the "Default.aspx.cs" codebehind page is just the default empty page generated by Visual Studio, and the TestControl.dll is a .Net library with a single simple UserControl, "SimpleUserControl", which just displays itself with a gray background and the "SimpleUserControl" label (as shown above).

The issue is reproducible on both Internet Explorer 6 and Internet Explorer 7.

When the issue occurs, I don't see any warnings or errors recorded in the Fusion Bind log, the web server's IIS log, or the client's Application Event log. (IE is generally pretty bad about providing any detailed error information when something goes wrong with loading a .Net control embedded in a web page, but there is usually at least some information recorded in one or more of these logs.)

My dev group is opening an incident with Microsoft Support for this issue. If we end up getting a workaround from them, or if I am able to come up with a workaround on my own, I'll update this post with the new information.

Update 3/6/2007: I've now discussed this issue over email and phone with Adam S., a member of Microsoft's ASP.NET developer support team.

Adam put together a simplified repro case for this issue with a simple .html (rather than .aspx) page showing that the problem isn't directly with the ASP.NET AJAX controls, but rather with Internet Explorer's implementation of displaying a Windows Forms .Net control that has been placed on a page by setting the innerHTML property of a <div> element with HTML that includes the control's <object> tag. (ASP.NET AJAX leverages the innerHTML property to do its content refresh of UpdatePanel controls, which is why I saw the problem happening with ASP.NET AJAX.)

Adam let me know that this IE bug with setting an element's innerHTML property with HTML that includes an <object> tag is tentatively scheduled to be fixed in Internet Explorer 8.

Of course, while a future IE8 fix for this issue would be nice, it isn't especially helpful to me right now, since I need to have my web application working on IE6 and IE7! For now, I'm going to rewrite my web app to use standard full-page postbacks to update the set of Windows Forms controls displayed on a page, instead of being able to update just a particular portion of the page using AJAX.

Partial Fix: "Address Bar [Url] is currently unavailable" in IE7

I previously posted about an issue in Internet Explorer 7 (IE7) where when an IE window is first opened, it hangs for a few seconds with a "Connecting..." message, and if the user tries to navigate to a new page while that message is still being displayed (generally by pasting an URL from the clipboard into the Address Bar and pressing Enter), the navigation fails with the error "[Url] is currently unavailable."

Based on several posts to the microsoft.public.internetexplorer.general newsgroup I looked at this morning, I've found a partial solution to this issue. One possible cause of the long "Connecting..." time in IE7 is the load time of the browser's add-ons.

I took a look at the active add-ons in my copy of IE7 (at Tools | Options | Programs tab | "Manage add-ons" button).

Somewhat to my surprise, I had as many as 30 or 40 add-ons enabled (among the 4 add-on categories shown in the dialog). Probably 80% of the add-ons were labeled as being from Microsoft and which I didn't remember installing; the other 20% were 3rd-party add-ons that I did remember installing -- things like Sun's Java plug-in, Google Toolbar, Macromedia Flash Player, and Adobe Acrobat Reader.

As an experiment, I tried disabling all of the enabled add-ons. I didn't know whether disabling the Microsoft add-ons would break my IE7 and result in it being unable to display web pages correctly, but I figured that in the event that it broke, I could always go back into the Options menu and re-enable extensions until IE7 was working again.

The experiment was a success! IE7 now initially starts up a lot faster, and I can immediately paste in and navigate to an URL via keyboard (Alt+d to focus the address bar, Ctrl+v to paste, Enter to navigate) as soon as the IE7 window appears.

Further, even with all add-ons disabled, I haven't run into any problems with displaying web pages in my brief testing so far. IE7 even displays XML documents correctly despite my having disabled many Microsoft add-ons with names like "XML Document".

I would imagine that I might need to re-enable at least some 3rd-party add-ons to view certain websites (like the Flash add-on for sites that use Flash), but for now, I am happy to use IE7 extension-free -- the delay in startup time was a significant annoyance for me. On the other hand, I could just use Firefox to view Flash sites and other sites requiring similar 3rd-party extensions; my copy of Firefox doesn't have any issues with startup time despite loading several extensions at startup.

I'm not sure why IE7 has this addon-related issue with startup time when IE6 did not. Perhaps one or more of my add-ons which were optimized to run in IE6 just perform really badly under the new IE7 engine, and future versions of the affected add-on(s) will address this.

One of the newsgroup posts I looked at also pointed to a built-in shortcut which runs an instance IE7 with all extensions automatically disabled for that instance; this is accessed (in Windows XP) from Start | All Programs | Accessories | System Tools | "Internet Explorer (No Add-ons)". Interestingly, when I launch IE7 from that shortcut, it is still affected by the "[Url] is currently unavailable" issue that my original copy of IE7 was affected by when attempting to immediately navigate to an URL when the window opens. This may be because opening IE with that shortcut brings up a window with a special "Internet Explorer is currently running without add-ons" homepage (including a yellow "information bar" at the top of the screen), whereas my normal IE homepage is a simple, quick-loading .html page hosted on my local machine.

If your copy of IE7 is starting up slowly with the "Connecting..." message, you may wish to examine the IE add-ons that you have running (Tools | Options | Programs tab | "Manage add-ons" button) to see whether one or more of them might be the culprit.

Update 2/3/2007: In the course of the past several days, I've had to re-enable several of the IE7 add-ons that I'd disabled to get various websites to work properly. Unfortunately, this has caused IE7 to mostly revert to the slow startup behavior, even though the majority of the add-ons that I had disabled remain disabled.

I've updated the title of this post to read "Partial Fix" instead of "Fix", as it seems just disabling all available IE7 add-ons to address the slow startup problem isn't a very good solution (since many web pages need one or more add-ons to work properly).

This issue is enough to make me hesitant to recommend upgrading to IE7 for any power users running Windows XP who hasn't yet upgraded from IE6. I say "power users" here because typical users are probably less likely be bothered by the extra startup delay -- it could easily be attributed to a part of the load time for the user's homepage if they don't attempt to immediately navigate to a different page, as I was doing when I first ran across this issue. And power users are likely to be already running Firefox or another alternative browser, and thus don't need to install IE7 to gain access to features like tabbed browsing and PNG alpha transparency support.

"Address Bar [Url] is currently unavailable" bug in IE7

I just ran across the following weird behavior in Internet Explorer 7:

• Open a new IE7 window.
• Fairly quickly (before the homepage begins loading), paste a valid URL into the address bar and press enter.
• An error message appears: Caption "Address bar", text "[Url] is currently unavailable."

The error doesn't occur if I wait a second or two after the windows opens before navigating to the new URL.

This may seem like a fairly contrived set of steps to take, but I wasn't hunting for IE7 bugs when I ran across this; I was just using the browser normally. It's a series of steps I do fairly frequently to quickly bring up a URL in a new IE window via keyboard: copy an URL to the clipboard, open the new IE window (Winkey | down arrow | Enter -- IE is the top item in my Windows XP Start menu), Alt+d to set the focus to the address bar in the new IE7 window, Ctrl+v to paste the URL, enter to navigate to the URL.

I have to think this behavior of IE7 is a bug -- at least, it doesn't seem like something that should be classified as "working as intended" or "by design"! And I never saw this behavior in several years of using IE6.

Browser window relative screen position

This morning, I noticed an issue with a particular popup browser window that my development team's browser-based application opens. With the application running in an Internet Explorer instance in the right monitor on my dual-monitor dev system, when the popup window was opened, it appeared in the center of the left monitor.

I decided to change this behavior to have the new popup window appear on top of the parent window, to make the appearance of the new window more obvious. I knew that the location of the new window could be specified relative to the screen in parameter 3 of the Javascript window.open(URL, windowName, windowFeatures) call in IE using the top and left attributes, like:

window.open('http://localhost/', 'newWindow', 'top=200,left=300')

What I wanted to do was supply top and left attribute values based on an offset of the screen position of the parent browser window. However, it wasn't clear to me how to get the parent window position.

Google searches such as javascript window screen position weren't much help -- no obvious solutions to my question among the first several pages returned. Searching on "location" instead of "position" was even less help, since the results included a lot of keyword collisions with the location (URL) property of the window object.

Eventually I did come up with a quirksmode.org page with the answer I was looking for by searching on "screenX", the attribute used with window.open on Navigator/Mozilla/Firefox to specify the horizontal position of a new window. The solution: In IE, the screenLeft and screenTop properties give you the horizontal and vertical positions of the browser window relative to the screen, respectively. (screenX and screenY are apparentely the equivalent properties in Mozilla, although I haven't tested this myself.)

On a page with frames, self.screenLeft will return the horizontal position of the current frame relative to the screen, whereas self.screenleft will give you the position of the browser window relative to the screen.

Interestingly, support for the screenLeft and screenTop properties apparently was first introduced in Internet Explorer 5. (This is why my copy of The Flamingo was no help in finding the solution -- my old copy is only current through IE 4.) This seems to indicate that in IE 4, you could set the position of a window (either initially in the window.open() call, or later via the window.moveTo() method), but there was no way to get the position of the window!

In any case, I was able to solve my original problem of the IE popup window appearing in the wrong place by getting the screen coordinates of the parent window using calls to top.screenLeft and top.screenTop, then adding a delta to each of those values and using the adjusted values in the call to window.open().

IE prompts for credentials when accessing an Integrated Authentication site in the Trusted Sites zone

I encountered a problem earlier today where when accessing a website set up to use Windows Integrated Authentication on my development machine across the LAN from my copy of Internet Explorer 7 (beta 3) on my test machine, Internet Explorer 7 was unexpectedly prompting me for credentials. I expected my credentials to be provided automatically via Integrated Authentication.

At first I thought that this might be an IE7-specific issue, but Googling for variations on "IE7 Integrated Authentication prompt" didn't turn up anything.

I then supposed that the issue might be a general Internet Explorer configuration issue, not specific to IE7. A Google search on "ie 'integrated authentication' prompt" turned up as its first hit a useful Microsoft Knowledge Base article, Internet Explorer May Prompt You for a Password.

Among other useful information, the article mentions that IE will prompt for credentials if it thinks the site being connected to is an Internet site (a site not located on the local LAN). This prompted me to check on my client machine IE's Tools menu | Internet Options | Security tab. In the Security tab, my web server machine was set as a member of the Trusted Sites zone.

I removed the web server machine from Trusted Sites and restarted IE. Somewhat ironically, Integrated Authentication then started working as expected; I could access the website on the server machine without being prompted for credentials. Apparently, at least in this case, IE interpreted the machine being present in the Trusted Sites zone as meaning that the machine was located out on the Internet (not internally on the LAN).

On another test machine running Windows 2003 Server that I used as a client to test the Integrated Authentication on my internal web site, I needed to not only remove my server machine from the Trusted Sites zone, but to explicitly add the machine to the Local Intranet zone before Integrated Authentication worked properly.

For both client machines, I had also verified that in the Internet Options dialog, in the Advanced tab, the "Enable Windows Integrated Authentication" checkbox was checked. (Apparently this checkbox is not checked by default on some Windows 2000 Server machines, which can cause Integrated Authentication to not work properly.)

IE7: Microsoft's Ctrl+Tab behavior rationale

Earlier today, Aaron Sauve from Microsoft's Internet Explorer 7 team made an interesting post to the IE Blog covering the IE team's rationale for the various default behaviors in IE7 with respect to multiple tabs.

As of the latest IE7 beta (beta 3), the default behavior when using the Ctrl+Tab keystroke to switch to the next tab (or Ctrl+Shift+Tab to switch to the previous) tab is to define the "next tab" as the tab to the right of the current tab as the tabs are displayed along the top of the IE7 window.

An alternative behavior, available via a checkbox in the Advanced tab of IE7's Internet Options dialog, is to have the Ctrl+Tab switch to the most-recently-used tab instead of the "next" tab. This is how the Alt+Tab application-switch keystroke works in Windows: pressing Alt+Tab once switches you to the application you were using most recently (not the application to the right of the current application's button in the Taskbar).

As I've blogged previously, I feel pretty strongly that the "most recent" tab switching order should be the default behavior for Ctrl+Tab. It's more powerful than the "left to right" behavior, as it can be used to quickly toggle back and forth between any two open tabs.

The reasons that Aaron gives for the "left to right" order being the IE7 default are:

• We value predictability over the more focused compare scenario.
• We want to be consistent with other apps that use tabs throughout the system.

Regarding the predictability issue: Let's go ahead and assume for the moment that the "left to right" behavior is in fact more predictable. However, I would expect that the Ctrl+Tab keystroke would be used most frequently by more experienced users. Less experienced users would probably be most likely to activate a tab by clicking the desired tab with the mouse. Given that keystrokes such as Ctrl+Tab will most often be used by "power users," I would argue that the fact that the "most recent" switching order behavior taking a bit more time to "get the hang of" is a lesser concern.

Regarding the issue of being consistent with the behavior of other applications, I went ahead and briefly tested a few other Microsoft apps that I have on my system. Of the applications I tested, Microsoft Excel was the only application that has a "left to right"-like behavior on a Ctrl+Tab press, in this case to switch between open workbooks. (And even this example is questionable, as Excel displays open workbooks in multiple Taskbar buttons, not in multiple tabs.)

On the other hand, Microsoft Visual Studio 2005 provides an excellent implementation of "most recent" order switching on a Ctrl+Tab press, switching between open windows which are displayed in tabs near the top of the window. Visual Studio even provides an "Alt+Tab"-like window that appears while the operation is in progress showing all of the available open windows that can be switched to.

As I noted in my previous post, the most prominent app that I use currently that by default provides "left-to-right" Ctrl+Tab switching order is actually Firefox! Having a better Ctrl+Tab order by default could be nice differentiator for Microsoft.

Given that "most recent" Ctrl+Tab switching order provides more powerful behavior, and that it will be primarily "power users" using the Ctrl+Tab keystroke, I would encourage Microsoft to reexamine the decision of whether to have the "most recent" behavior checkbox under IE7's advanced options be enabled by default.

Fix: "Object doesn't support this property or method" on a Windows Forms control built with VS 2005

At the office recently, I was asked to whip up a simple Windows Forms UserControl with a public method and run it embedded in an HTML page in Internet Explorer. "No problem," or so I thought at the time -- I had created similar simple controls in the past, and one of the components that I have primary responsibility for at work is an Excel-like Windows Forms spreadsheet control that is deployed embedded in web pages and run in Internet Explorer. (More information on running Windows Forms controls in IE in this manner is available at GotDotNet .)

I had the control up and running in a web page in just a couple of minutes:

• I opened Visual Studio 2005 and created a new C# Class Library project.
• Added a new User Control to the project, "SimpleUserControl".
• To ensure that the control would stand out on the web page, changed the background color property of the control to Blue, and added a label to the control with the text "SimpleUserControl".
• Added a simple public method to the control: public string WhatTimeIsIt() {     return DateTime.Now.ToString(); }
• Compiled the project, and copied the generated SimpleUserControl.dll to a folder under my IIS root directory.
• Quickly typed up a simple HTML page in the same folder to show the control and demonstrate a call to the public method: <html> <body> <object id="SimpleUserControl"   classid="http:SimpleUserControl.dll     #SimpleUserControl.SimpleUserControl"   height="150" width="150" VIEWASTEXT> </object> <input type="button" value="What time is it?" onclick="DoWhatTimeIsIt();" /> </body> <script language="javascript"> function DoWhatTimeIsIt() {     alert(document.SimpleUserControl.WhatTimeIsIt()); } </script> </html>

I brought up the web page in IE and the SimpleUserControl displayed correctly, as expected. Unfortunately, clicking the button on the page, instead of returning a string with the current date and time, generated a Javascript error: "Object doesn't support this property or method".

I double-checked everything I'd done. (No, I hadn't misspelled the method name in the Javascript code... Yes, I really had declared the method to be public in the C# class...) Another one of the senior guys on the team plus my boss (who was the lead developer on the team prior to his promotion) also puzzled over this problem for a while without being able to figure it out.

Finally, my boss came up with the solution: In Visual Studio 2005, in the project properties, on the Application tab, in the Assembly Information dialog, the "Make assembly COM-Visible" checkbox (which was unchecked by default) needed to be checked. After doing this (and rebuilding the project, re-deploying the .dll file, and reopening the IE window), the button could successfully call the public method.

I was pretty surprised by not having run across this issue before. Apparently, though, in Visual Studio 2003 there is either no equivalent checkbox or it is checked by default (and thus similar controls which I had previously created, which worked fine, must have been created using VS 2003). Also, Visual Studio's migration wizard which upgrades VS 2003 projects to VS 2005 projects apparently checks the checkbox by default, which is why we didn't run into this issue after upgrading our product to use VS 2005.

Fix: Can't hit Visual Studio breakpoints when debugging Windows Forms app in browser

In the past, I've run into a problem where when trying to debug a .Net Windows Forms application running embedded in an Internet Explorer window in Visual Studio, breakpoints will not be hit in the debugger. I've seen this issue myself in Visual Studio 2002 and 2003; a colleague just told me that the issue is apparently present in VS 2005 as well.

The solution is in the Project Properties dialog/pane, on the Debug tab, instead of checking the "Start browser with URL" radio button, the "Start external program" radio button needs to be checked instead. In the text field for "Start external program", enter c:\program files\internet Explorer\iexplore.exe (or wherever your local copy of iexplore.exe is located).

Optionally, you can enter the URL of the web page that you want to be initially loaded in the browser in the "Command line arguments" field.

Another thing to verify is that the <object> tab in your web page is pointing to the current debug version of your application's .dll file.

Once that is done, you should be able to successfully hit breakpoints when debugging the application running in the browser.

Ctrl+Tab and IE 7

While I was on hold with Microsoft support recently, I decided to download and try the new public beta release of Microsoft Internet Explorer 7 on my test machine.

Overall, it feels a lot like a Firefox clone -- which isn't a bad thing. Firefox 1.5 has recently become my primary browser of choice for all pages and applications except for those which only play nice with IE. Prior to switching, I had used IE 6 for everything. (I had briefly tried Opera 8, but I ended up dropping it because it locks up my work machine for about 10-15 seconds while it is first starting up, and it doesn't support some keyboard shortcuts supported by IE that I tend to use automatically such as Ctrl+Enter to prepend "www." and append ".com" in the address bar -- Alt+d, "google", Ctrl+Enter takes me to the http://www.google.com site.)

One thing that I don't like about Firefox 1.5, however, is the behavior of Ctrl+Tab. When there are 3 or more tabs open, then repeated presses of Ctrl+Tab activate through each tab in order. Unfortunately, the IE 7 team has dutifully cloned this behavior in the current beta version of IE 7.

The behavior I would want to see is having Ctrl+Tab work like Alt+Tab does in Windows -- a press of Alt+Tab activates the most-recently-used window, not just the "next" window. This makes it very convenient to rapidly switch back and forth between 2 windows that I'm using at any given time.

There is a good Firefox extension available to fix the Ctrl+Tab behavior, LastTab. I'm willing to install LastTab on each of my machines since (1) FireFox makes it so painless to install extensions, and (2) I'm aware that any machines other than my own are not likely to have Firefox installed so I'll just be using IE on those machines anyway.

However, as soon as IE 7 is released, it is likely to become the new corporate standard at most businesses. For this reason, I would like to see the IE 7 team get the Ctrl+Tab behavior "right" by default, so that when I'm using someone else's machine I can Ctrl+Tab between tabs without being annoyed by the behavior, regardless of whether it might be easy to fix the behavior on my own machine by using an extension.