Microsoft Silverlight in Safari for Windows

June 11, '07 Comments [14] Posted in Musings | Silverlight

Sponsored By

After I installed Safari for Windows, the second thing I did was see if it would run Silverlight. I loaded up the Airline sample that I had running locally on my machine and got this.

Silverlight Airlines Demo

From this I glean that the JavaScript detection code isn't digging Safari on Windows. So...checking my HTTP UserAgent gives me:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en) AppleWebKit/522.11.3 (KHTML, like Gecko) Version/3.0 Safari/522.11.3

...but on Mac it's usually:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/XX (KHTML, like Gecko) Safari/YY

...and since it's not Silverlight but rather the JavaScript that makes the decision on whether to try to load Silverlight (and considering that Flash and what-not worked in Safari without be needing to reinstall any plugins).

I opened up this app's Silverlight.js file and added an alert() around line 85:

var versionStr = detectAgControlVersion();
alert(versionStr);

...and it reported 0.8.5. That means that Safari can see the plugin on the system, but the version should be 0.95.

I figure that the Silverlight Team is already all over this, so rather than solving the problem for them, I added:

agVersion = "0.95.0";

...around line 65 to force the issue. This got Silverlight loaded into memory, as seen in the Process Explorer screenshot below...

...but nothing showed up. Blank screen. No amount of windows jiggling or resizing (to force a paint) would get it going on my system.

UPDATE: Tim Heuer tried the same thing and says the Silverlight Team is on it and that Safari smells like Opera to Silverlight. He also says he was able to get a control to show while I was not.

If this browser is going to get some share (and it likely will with 1 million iTunes downloads a month - they'll likely bundle it virally) then Silverlight support is a must.

Technorati Tags: Safari, Apple, Mac, Silverlight

« Safari for Windows - First Impressions | Blog Home | Video: Windows Browser Speed Shootout - ... »

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. I am a failed stand-up comic, a cornrower, and a book author.

About Newsletter

Sponsored By

Hosting By

Comments [14]

Permalink

Tuesday, June 12, 2007 12:09:20 AM UTC

I'm sure it won't be long before silverlight support is seamless in Safari for windows. They have some time to iron it out since Safari on Windows is still in Beta for a while.

I tried Safari today and wasn't impressed. Besides the annoying UI conventions (close tab button on the LEFT? This is Windows guys, thats just annoying), it didn't seem to add anything compelling. It did seem to be a bit faster but the text rendering was bad compared to IE and with 3 solid browsers on Windows already (IE, Firefox, Opera, all of which look and behave like Windows apps) I think it will be a tough sell for Safari. Of course, if there is an auto-checked option in the next iTunes update that goes something like "Install Safari and make it my default browser" they will likely get some major market share.

Nate

Tuesday, June 12, 2007 12:37:32 AM UTC

Hi Scott,

It seems to have worked for this guy.

http://turtle.net.nz/blog/post/SilverlightWindowsSafari

Cheers

Hemil

Tuesday, June 12, 2007 2:55:44 AM UTC

Hey Scott, I went on a similar quest. I didn't have a SL application local, so I didn't change the JS at all, I just went back and tried reinstalling both 1.0 and 1.1 beta. After restarting Safari, and trying some of the SilverLight showcases, I found that I could get it to run (the xbox campaign played sound for instance), but I just got a black box where visual content should be. I don't believe this is a simple javascript fix.

Ryan Beesley

Tuesday, June 12, 2007 10:39:33 AM UTC

Whilst I'd love to see Silverlight in Safari/Windows too Silverlight just isn't important enough yet to be the make or break you imply.

[)amien

Damien Guard

Tuesday, June 12, 2007 4:36:52 PM UTC

FYI, it is not permitted to alter the silverlight.js file itself...

timheuer

Tuesday, June 12, 2007 4:51:09 PM UTC

clarifying: the silverlight.js file is specific to the detection/version checking of the browser/platform and then provides links to the installation points. altering these detection scripts isn't supported as the scripts do specific detection and point to specific, supported installation points. in creating/instantiating the control (i.e., what happens in createSilveright.js sample) you could specify a property that ignores the browser versions (ignoreBrowserVer) and doesn't do a supported browser check...

timheuer

Tuesday, June 12, 2007 5:14:53 PM UTC

(rolling my eyes at timheuer)

Scott

Tuesday, June 12, 2007 8:46:57 PM UTC

It's sad how geeks think a like. I was running into the same issues and wonder...What Would Scott Do? (WWSD) ;-)

The fact that we're using Silverlight 1.0 Beta on Safari for Windows Beta 3 is sweet. I like to follow this mantra:
- Beta on Beta => Good
- Alpha on Beta => Iffy, but Good.

Javier Lozano

Tuesday, June 12, 2007 9:57:21 PM UTC

scott: rolling eyes...because i didn't clarify in the initial post? apologies :-)

timheuer

Tuesday, June 12, 2007 11:25:42 PM UTC

hehehe, yeah that's it Tim.

I thought, "not ALLOWED to modify a javascript file?!" I didn't see the second one until after I posted.

The second explanation makes more sense.

Scott

Wednesday, June 13, 2007 12:05:15 AM UTC

okay cool, yeah -- giving a developer a text file and saying "don't do" is a lot like leaving a room with your 3 year old and a bar of chocolate in it...glad i could clarify though (and slapping my own hand for not doing it in the original comment)

timheuer

Thursday, June 14, 2007 9:51:20 PM UTC

Tim: even though i might be mistaken, I'd say that Scott's alteration is necessary. If i recall correctly, setting the ignoreBrowserVer to true will suppress browser detection but it'll still check for the current version of Silverlight and it'll fail for the reasons mentioned by Scott (ie, you'll have no browser detection but the code for checking if the requested version is installed will run and it'll fail).

Luis Abreu

Friday, June 15, 2007 12:05:27 AM UTC

luis: well, let's just remember we are dealing with a beta product on a beta product :-). we have to give both time to mature and get it right. silverlight will support major, released browsers. safari v3 is not released. perod. while it *may* work it is not even on the matrix for beta for silverlight. that aside, you can change the version parameter to 8 on the creation script and it will work as well...neither workaround of course is supported/recommended -- 'work' is a relative term of course...it should be 'render' -- whether all silverlight api's will 'work' is another question.

i was able to get it to 'render' without modifying silverlight.js -- again, let's give both platforms time to mature...i think the teams are aware of what the right things to do are.

timheuer

Friday, June 15, 2007 9:38:12 AM UTC

Tim: agreed. And i believe that the point in having an early beta is getting feedback, which was what i was trying to do :) I wasn't complaining about Silverlight not working on Safari. I only said that ignoring browser detection wasn't enough for making it load on safari for windows. And your last work-around (changing the version) is better than Scott's so it's the one that should be used with the current bits

However, and this is only my opinion, maybe adding an extra parameter to the createObjectEx is a good idea. At least, that's what I'm proposing here:

http://msmvps.com/blogs/luisabreu/archive/2007/06/15/silverlight-extra-parameter-on-the-object-that-is-passed-to-the-createobjectex-method.aspx

Luis Abreu

Comments are closed.