Plugins:PluginDirectory/HowPluginDetectionWorks

From MozillaWiki
< Plugins:PluginDirectory
Revision as of 02:26, 19 February 2010 by LesOrchard (talk | contribs) (Created page with 'Building a service to help keep plugins up to date is hard. __TOC__ == Browser identification == The first step in the process is identifying the user's browser. This consist…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Building a service to help keep plugins up to date is hard.

Browser identification

The first step in the process is identifying the user's browser. This consists of determining values for the following properties:

appID
A unique identifier for the browser application (eg. {ec8030f7-c20a-464f-9b0e-13a3a9e97384}, Safari)
appRelease
The official release version number for the browser (eg. 3.5.8, 4.0.4)
appVersion
A more specific indicator of the release build (eg. 20100202, 531.21.10)
clientOS
An identifier describing the OS on which the browser runs (eg. Intel Mac OS X 10.6)
locale
The primary locale / language chosen by the user (eg. en-US, zn-CH)

Although most plugins are compatible with a wide range of values for the above properties, it is possible for plugins to assert compatibility with any permutation of these identifying properties.

Client plugin scan

Most browsers expose data on installed plugins to client-side JavaScript via a property named navigator.plugins. (Microsoft Internet Explorer is an exception to this rule, but more on that later.)

navigator.plugins

The navigator.plugins property may be used as a list, with each element in the list representing an installed plugin. Each of these elements generally exposes the following properties, each assigned by the plugin author or vendor:

name
A short name for the plugin
description
A longer full-text description
filename
The filename of the binary library containing the plugin's executable code
mimetypes
A list of MIME media types the plugin claims to handle

You might notice that this list is missing a few particularly useful details:

No GUIDs or UUIDs

There is no unique identifier, such as a GUID or UUID.

This means that we'll need to use a combination of all of these properties to uniquely identify a plugin, any of which has the potential to change between plugin versions.

For example, the plugin for Adobe Flash has gone through many changes throughout its lifespan, both through changes in the name of the product itself to the acquisition of Macromedia by Adobe.

Version is not directly exposed

A version property is not supplied by most browsers for plugins in navigator.plugins.

While most plugins include some expression of a version in the name or description, this version does not always exactly match the fully qualified version of the plugin.

For example, use the Tools > Add-ons menu in Firefox to open the Add-ons dialog and view the Plugins tab. If you have "Shockwave Flash" installed, you may see it reported as version 10.0.45.2.

However, this version is not usually available via navigator.plugins. So, instead, client-side detection code has to inspect the name or description - which lists the version as "10.0 r45".

And, what's worse: Some plugins don't include a version number at all in either the name or description. In this case, there's not much we can do besides shrug and report the version as undetectable.

Firefox 3.6 and above does offer a separate version property


Server-side plugin search

Client-side plugin matching