Silverlight and Firefox...

I'm going through the SilverLight 4 training course and it only reliably works with IE. I'm wondering if this is a known problem and if so, is the problem with FireFox or the SilverLight runtime?

We have written a couple large LOB applications in Silverlight and have not had any appreciable differences between IE and Firefox and even Safari for that matter...

I reality though our apps are all Silverlight, the Training Course sites are typically a mix of ASP and Silverlight and as such I KNOW there are issues or you can write sites that will work in IE and not work in Firefox using ASP and other web technologies... Perhaps you are encountering some of this...

Additionally various extensions and plugins for Firefox and IE can have a detrimental effect of the wib sites shown within. Have you tried to deactivate any of these that you might have installed in your environment

@harlock123: Thanks. I had hoped for that to be the case.

No I only run 2 extension for Firefox which is no script (which I fully enable where it asks for the training course)  and download helper. Neither have given me any greif before when "using" Silverlight, but I should know better that the development environment is different.

If you don't mind me asking, how has your experience been with Silverlight and LOB applications? I'm somewhat slowely getting my head around WPF & MVVM LOB and was wanting to translate that effort into a shorter learning curve with Silverlight. I hear that one can build SilverLight web application prototypes quicker with SilverLight than ASP MVC. I've got some ideas that I'm itching to flesh out, but currently trying to learn the pros and cons of each web technology out there with nothing to show for it.

Well...

I love silverlight development, but there are a lot of things to wrap your head around. Personally having come primarily from client server winforms development there are a number of things that can bite you on the backside. Now being a web developer already might have helped this a bit.

Examples

One being the Webservice calling paradigm that is very different IE set up a call back, then call a method, then handle the results in the call back.

Another being the application of a client server like dialog for the users of the application. Ie Windows with stuff to interact with and what not. (We used windowing controls from Telerik and Component One)We found though that using component one stuff inside of a Telerik Window might cause problems with Modality and the window not popping up on top of everything else.That sort of crap never happened on winforms only stuff or a WPF application.

There are definately ways to make a silverlight app consume memory without freeing it inadvertantly (A memory leak). We use Silverlight Spy to help find these sorts of conditions

Overall though a great environment and definately better than plain old ASP.NET or AJAX from a user interface perspective. All in all though when we started this odessy the cookies were not yet done fully. (Over 1 year ago). Printing and support for exporting to office apps being a significant omission in the early days, but any web guy will tell you Printing from Web browsers stinks even today silverlight or no silverlight.

Thanks for that. You would think the declarative XAML would mitigate controls not playing well together and reduce the chance of memory leaks, but I guess the recipie still needs refining.

Unfortunately I'm not doing this with a team, so I've got to create two concurrent applications; the real one and the prototype/proof of concept for show to people for help and support when I get stuck. Nothing like getting bugs at different places trying to do that same thing and explaining that to someone.

I've been lucky to be able to be an assembler of applications so far; started com at VB6, VBA at Office 97, .Net at version 2, so I've been holding off the web stuff until I hoped the kinks were mostly knocked out, but I'm starting to get older and more impatient because of that.

Even the html dom model of scrollwidth on IE == Chrome == Safari != FF and when you set an element with style=overflow:auto;height:10px, on IE == Chrome == Safari != FF. So yeah, it is hard to garrantee anything.

@magicalclick: I take it then that you're a HTML (ASP?) developer. Have you tried Silverlight and if so which has been better for what?

I haven't get my hands on SL actually, so, I can't say anything about that. But, HTML and DOM on cross broswers is just plain horrible. Stuff like what I said is just a tip of the iceberg.

But, have you heard of jQuery? It is Javascript based, which you thought it should work on all browsers? Nope, Chrome will have exception and terminate all scripts if you tried to $("#myObjID").width() on a display:none domObj. It makes the domObj visible and crash. When on IE and FF, they are fine. 

Stuff like this usually has interaction with the browser, and it is expected to fail at some point because you cannot garrantee the interaction is always 100% correct. Just like the DomObj.scrollWidth. Once you are going to interact with browser, it will fail at certain point.

Exactly why I stayed away until the advent of Silverlight.

However I will say that the apps we have written are 100% silverlight. Are a fixed size within the browser, (ie as you play with the browsers window size the app stays the same dimensions and scrollbars appear or dissappear accordingly)

As for the declarative XAML preventing detramental component interaction, they are still components that are running code within them. The Xaml simply describes form and format not function except in allowing wireup of events to your own code.

Overall though a hell of a lot better then the ajax dom interaction mess that is regular web development. I suppose flash is simillar in that respect to silverlight but I just couldn't bring byself to learn yet another language. I only have so much grey matter up there to stuff crap into, soon I would be forgetting things like how to tie my shoes.....

Still fun all round trying to do web programming in every language...

Ok, then as Silverlight is a client side technology with Web Services being the server side, then could one Silverlight application redirect or transfer control to other seperately installed Silverlight applications on the server? Or do they all need to be in the one application and use MEF to branch out? What about to another ASP.NET application or is that a no-no?

I want to rewrite and prototype some different application ideas for the net but keep them seperate. ie. Alternate login that doesn't require username & password and easier to remember but just as (or more) secure, self organise or replace blogs as searching via tags and dates when trying to track a series is painful, better organise and catagorise tutorials, samples, blogs of disparate information where the content creators and consumers both play a role in sharing the learning experience as forums are too slow and laborius and googling/binging doesn't extend past the search if you don't get the answer you want.

??? I am not experience on this at all, but, I thought you use WCF. Have you looked into that yet?

As far as my understanding currently is WCF (Windows Communication Foundation) enables the Silverlight application to communicate with the Web Services on the server. The problem is that the server also has to serve the Silverlight application as well from IIS, so the question is: does IIS treat each Silverlight application as an URL end point or as a reference from an ASP.NET host? From the learning courses on Channel9, I get the impression as it's a reference from a ASP.NET file which I think means no cross site scripting or in other words, as seperate URL end points with their own folders. Though I can easily be wrong...

@N2Cheval:

I have had to implement the CrossSite control files on our Silverlight applications that are served from the same servers as the webservice endpoints. IE the crossdomain.xml files allowing said cross site scripts. Generally this file has been a little more restrictive than allowing any site to script into any other local site. (Like the default ones you find via google searches)