I spent a chunk of time recently trying to figure out how a web developer could pre-test a user’s browser configuration to determine whether some kind of identity selector client or plugin will pick up on the embedded HTML object and give the user a little infocard-love, if you know what I mean :)
It’s a little messy. Ok it’s a lot messy.
The CardSpace team has given us a way to test whether their client is installed (which I really appreciate), but sadly, the way that they have given us can only be evaluated using a scripting language that runs on one brand of browser. What we all really need is a way to tell if *any* identity selector is installed or, in a future perfect world, *which* identity selector is installed, in a vendor-agnostic way.
Sadly, the browser wars have completely derailed ease and simplicity in determining capabilities for embedded content. It’s hard for me, looking back, to imagine what possible reason the IE6 team might have had for choosing to populate only part of the ‘navigator’ object in Javascript. Why would they choose to populate navigator.appName and navigator.platform, but leave things like navigator.plugins and navigator.mimetypes blank? And why would they choose the worst *possible* way not to support it, by returning a valid but empty array every time, making it impossible to tell the difference between a call to a supporting browser that happens to have a negative result, and a call to an nonsupporting browser that may still actually have the plugin you want installed? Sadly, this functionality appears to not have changed for IE7 either.
In my wildest happiest dreams, I would test once to see if the ‘application/x-InformationCard’ mime type is registered. If it isn’t registered, I would test no further, and send the user to a “getting an Identity Selector” help page.
If the mime type does exist, I would (in my happy dream) find out what plugin is registered to the the above mimetype. I might also check the plugins list to find out whether there were any other known identity selector plugins that were installed but either disabled or not the default. I could then tell the user exactly what plugin it is that is handling their identity selector needs. Wouldn’t that be a nice and user-friendly? Instead, I’m stuck trying to jump through the same nasty hoops that the people trying to detect Flash versions go through.
Don’t believe me? Look at the scripts that are written to accomplish what should really be a simple task.
After all this angst, I can only report varied results. It is obvious to me that this is not a piece of code that you can write and walk away from, because it can’t possibly be vendor-agnostic. The identity selector detection script will have to be tweaked and coddled and monitored forevermore, just like the flash detection scripts.
Right now I have three possible clients to detect. If I want to detect the CardSpace client without using VBscript, it seems reasonable to assume that if I parse navigator.appVersion and see both “MSIE 7.0″ and “.NET CLR 3″, life is probably good, good enough to know that at least one identity selector is installed. If, in the future, the user had both CardSpace and the OSIS identity selector installed, I’m not sure how you could determine which one was active. Chances are you could use VBscript for that, but then you would have to do something in the case that VBscript is disabled…
In trying to detect Ian Brown’s Safari plugin, I’ve found that navigator.mimetypes shows that the “application/x-Informationcard” mimetype is registered, but I can’t derive an enabled plugin from navigator.mimeTypes["application/x-informationCard"].enabledPlugin, I’m not sure why. I will keep working on this and let you know.
I can’t detect Chuck’s Firefox plugin at all, because it isn’t a plugin, it’s an extension, and extensions are considered private by the browser. I can’t even tell that the “application/x-informationcard” mimetype is registered. I don’t think there is any fix for this, except perhaps asking Chuck very nicely if he could look into what it would take to move away from an extension and towards a plugin.
Well, that’s the report from the trenches. Pete, you may be right, perhaps all we can do is to let the user fail, and then try to explain it to them after the fact. The sad thing about being forced to be reactive instead of proactive, is that when the html object is invoked but no token is returned, there can be a number of root causes. Trying to explain them all to the user will make their head spin around — which leads me to another little thing I’m working on, you’ll hear about that pretty soon :)
Hey CNET:
