Since I initially wrote this post, I found another way of solving the Safari / Chrome ASP.NET menu issue.
First, determine whether the user agent string contains "AppleWebKit". If so, set the Page.ClientTarget property to "uplevel".
protected void Page_PreInit(object sender, EventArgs e)
if (Request.UserAgent != null && Request.UserAgent.IndexOf("AppleWebKit", StringComparer.CurrentCultureIgnoreCase) > -1)
this.ClientTarget = "uplevel";
NOTE: I have found from personal experience that the Request.UserAgent property in some cases might not be set. It is best practice to ensure that the user agent string is not null before calling the string's IndexOf method, otherwise, the code will throw a null reference exception.
Typically, you will not want to handle this event on every page that you have the ASP.NET menu, unless you have a tiny website.
Set the pageBaseType in the Web.config file to a class that inherits from System.Web.UI.Page and contains the above code.
is another blog post on the menu problem.
Primarily, I develop external facing commercial Web sites. In this setting, I cannot dictate which Web browser will be used by the masses, so I have to proactively ensure that the layout and functionality remain either the same or gracefully degraded.
This can be a challenge when Internet Explorer 5/6/7, Mozilla Firefox, Apple Safari, and Opera Web browsers might adhere to differing standards.
I found an article that describes a situation with the Apple Safari browser wherein ASP.NET renders the ASP.NET Menu control in a downgraded (not gracefully either) state. I have seen this issue a couple of times in the past several years and I thought it was worth mentioning.
I will not go into much detail here, but in brief, in the %SystemRoot%\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers\mozilla.browser file, remove the Menu adapter reference from the Safari configuration, save the file, and then run the aspnet_regbrowsers.exe -i tool. Running that tool parses and compiles all system-wide browser definitions into an assembly and installs the assembly into the GAC.
Typically, if only administering a single Web site, the preferable approach would be to create an App_Browsers folder in the root of the Web site and create a .browser file in that folder. Add the appropriate browser overrides in the file and you are good to go. No need to run an external tool. The browser configuration is dynamically compiled when the application starts. This is the only approach if the Web site is in a hosted environment.
In some future post, I would like to dive into a discussion of what are the major headaches that developers face when attacking browser compatibility issues and how to elegantly circumvent the browsers' woes.
What are the three or four issues that you find most irritating when developing for various browsers?
Hope this helps!
The long awaited release of the .NET Framework Library source code for debugging purposes has arrived.
Scott Guthrie announced it here. Scott Hanselman and Peter Bromberg blogged about it here and here.
One of my mentors, John Robbins from Wintellect, has a great blog about this subject.
I am really excited about this and I look forward to taking advantage of this in the near future.
Hope this helps!