Back to the land of browser inconsistencies :¬(

I had such high hopes for the silverlight plug-in.  Cross-browser incompatablities can be the most time consuming areas of web development, so a browser plug-in overcomes these by sandboxing the application so it handles all of it's rendering internally

Or so I thought.  Having developed all my silverlight under Internet Explorer, everything renders fine with the default 100% heights and widths.  Rendering the controls is important for templated controls and the loaded event only fires when the control is rendered and the loaded event is important in order for the control to pipe up and accept some data from the dartabinding process. 

To my amazement, and slight relief, Firefox actually requires a fixed height in order for it to render.  By default, you are given a silverlight plugin, set to 100% height and width, wrapped in a div with a height : 100% style attribute.  Just change the containing div to a fixed height and your controls now render fine in Firefox :¬)

so from this

to this

<asp:Silverlight ID="Xaml1" runat="server" Source="~/ClientBin/NavTeqBannerMain.xap" MinimumVersion="2.0.31005.0" Width="100%" Height="100%" InitParameters="ctlid=SilverLightBanner" />

</div>

It's fair to says IIS7 has some differences when compared to IIS6 (Well, Duh!)

The one I found most difficult to get my head around was the Wildcard Handler Mappings.  Traditionally, we wrote the handler in .net, or used the global.asax file to map the requested re-written URL to a pgae in the application.  IIS6 had the option to specify whether or not the file exists.

For example, you request http://www.creative-jar.com/News.  There is not physical file called News in the root, and even if there was, there's no extension on the file in the URL so IIS wouldn't know which dll to map it to, generating a 404 beacuse the file isn't found.  So, you set the WildCard handler to NOT verify that the file exists, before passing it to the handler to do it's magic

It's this Verify File Exists option that's missing in IIS7, causing the 404 to fire before your handler even get's a bite of the apple.

I found a good post on the subject here.  It explains the extra steps you need to get IIS7 not verifying files in your web application, instead just passing the whole request to your app and let it carry on as normal.  The post links through to an open-source UrlRewriting HttpHander called UrlRewriter.NET which has such a simple setup, it's untrue.  It currently uses a section of the web-config to work out it's mappings but, being that it's open-source, you can change it to collect from wherever you like

enjoy :¬)

Came across an interesting bug on one of my client's sites the other day. She was having problems with a link being pushed off her screen. So following the basic diagnosing a problem rules, I found out she was using Firefox. Checked that it was fine no problems. So naturally asked her to provide a screen shot. Snap shot below.

As you can see this was most strange as her browser had added in all this additional formatting around the phone number, causing the email link to be pushed out. Naturally this intrigued me to find out what was causing it, so after looking on several forums found out that it was a Skype Plug-in on Firefox. So basically when you browse a website and see a phone number on the site, the Skype extension automatically converts it into a button that you click to call the person using Skype. Although quite handy for some, very annoying for others, and looks like Skype secretly install it without you knowing.