Recently, we completed development on a Silverlight interface for LOOP Exchange.  During this development, we ran into some interesting issues with some fairly simple solutions.

Woe # 1
The first issue we ran into involves file downloads.  Downloading a file in a browser requires a user to initiate the process.  This is a security precaution and it makes perfect sense.  The problem comes in when you try to have a Silverlight control, when clicked on by a user, initiate a download.  In Firefox, this works without a problem. However, IE decides that this isn’t user initiated, and if you want to allow it, you must specifically okay the action.  If you choose to allow it in IE, this reloads the entire page, bringing you back to the start of what could be a long set of forms.

This was unacceptable for us when looking at it as a user, especially considering the purpose of creating this interface was to provide a smoother user experience.

Solution #1
Our solution is to simply open a new window, and have that new window initiate the download.  When the user is asked to allow this action, the reload only reloads that new window, so the user isn’t shot back to the beginning of anything.  To make this solution as robust as possible, we do a browser check from within Silverlight.  If the browser is one we know supports downloading within the same window (e.g. Firefox), we go ahead and do that, otherwise we open the new window for the download.

Woe # 2
The second issue was in some ways more major, but it also had a much easier fix.  We were having problems any time we tried to embed the Silverlight control outside our own domain.

Solution # 2
After much debugging, we tracked the issue down to the communications between the control and our server.  Google came to the rescue, as it so often does, and we found an easy solution.  Silverlight controls use a browser’s native connection system for making http requests.  This has a number of benefits, including cookie passing, that are very desirable.  For security reasons, the Silverlight embed code, using the html tags rather than the javascript embed, doesn’t allow for access to the page and browser functions by default.  To get this access, include the following inside your object tag:

Woe #3
For our latest problem, we are still looking for a solution.  Within our Silverlight interface, it should be possible to log in directly if the DDP is marked as private.  This login box uses internally the same function that is being used elsewhere.  In Firefox, this login works smoothly, without any problems.  In IE, the login button causes the request to go to the server and we get the proper response, but the cookie is never set client side.  The strangest part of all is IE7.  If we have a second tab open in IE7 when we click on the login button, it works without a problem, just like in Firefox.

Solution #3
Let us know if you have any ideas — email me.

Working with Silverlight has, overall, been a very pleasant experience.  There are still some problems, as you might expect from a beta product, but development was fast, and the cross-browser consistency of the interface is a nice change from normal web development.