522585 - use navigator.plugins[id].version for version information on plugincheck page

Status: RESOLVED FIXED

(www.mozilla.org :: General, defect)

Description

[Christopher Blizzard (:blizzard)]

Firefox 3.6 on windows includes a .version attribute that exposes the dll version to web content.  We can use that to give a higher-fidelity version detector for people on 3.6.  Here's a script that demonstrates it.

http://www.0xdeadbeef.com/~blizzard/plugin-version.html

And a screenshot from 3.6 on Win 7:

http://www.0xdeadbeef.com/~blizzard/images/plugin-versions.png

Comment 1

[James May [:fowl2]]

How would this relate to bug 127361?

Comment 2

[Kohei Yoshino [:kohei]]

Firefox 3.6 is coming soon... The current version parsing doesn't work with most plugins, so this bug should be fixed asap to improve user experience.

Comment 3

[Lloyd Trevor Hilaiel]

+1

This tactic works on osx as well, provided the plugin developer correctly sets the "CFBundleShortVersionString" element of their plist bundle.

Comment 4

[Kohei Yoshino [:kohei]]

Is there an uncompressed version of plugincheck.js? It's difficult to make a patch for the current compressed file.

Comment 5

[Lloyd Trevor Hilaiel]

Kohei,

I myself forked this project for a related fix:
http://github.com/ozten/Perfidies-of-the-Web

Given comments in js I believe that to be the canonical home of plugincheck.js

My fork also fixes the test harness that outputs a json representation of your plugins:
http://github.com/lloyd/Perfidies-of-the-Web

good luck!
lloyd

Comment 6

[Austin King [:ozten]]

(In reply to comment #5)
Lloyd, I'm excited to incorporate your patch, but the reason we aren't using the new version property in production is that we have to support multiple versions of Firefox in the backend PFS service, as well as in the web JS code.

Perfidies and PFS currently aren't cross browser, or multi-version for a single browser. Given a mime-type and an app id, PFS returns a list of known plugins and their releases. Each release has a version string and a status. 

Given the Firefox app id we return a more "coarse" version number since before Firefox 3.6 we have to use the version in the plugin.name. 

Example: Flash on Mac
plugin.description - 10.0 r32 
plugin.version - 10.0.32.0

So we either need to give PFS more context (Firefox version perhaps) or PFS needs to return "version aliases" or something so that we know both of these values.

We could do 1 off JS to map these versions against each other of course, but we have plans to implement cross browser support. This will fix it systematically and allow us to use plugin.version w/o any special rules when interpreting the PFS response.

Again, looking forward to pulling your github code, and I'm pretty sure we'll need to make some tweaks to PFS before we can push this out, thanks again for working on this!

Comment 7

[Les Orchard [:lorchard]]

The thing I was pondering was to split "version" up into something like these release properties:

* "detection_scheme"
    * 'original' for scraping version from name/description,
    * 'version_available' for using the version property.
* "detected_version" 
    * the version detected using the identified detection scheme
* "vendor_version"
    * the version intended by the vendor, ie. what you can see in the Tools > Addons > Plugins dialog.

Perfidies in JS can determine what "detection_scheme" it can use, and pass that as a search term to the PFS2 query along with appID / locale / platform / etc.  That context would allow it filter for results useful for that scheme, if possible.  And I think that might also work better than browser version, because many versions and platforms will fall under the same detection scheme.

Ideally, detected_version and vendor_version should match - especially for the hypothetical 'version_available' scheme.  But, for the 'original' scheme, they may differ thanks to the possible loss of precision in detecting version.

And, where detected and vendor versions differ, we could introduce some new statuses - say 'maybe_latest', 'maybe_outdated', or 'maybe_vulnerable' to suggest a user should manually double-check the fuzzy result, and how urgent that manual step might be.

So, for example, say there's a vulnerable v10.0.32.68 and a fixed v10.0.32.72 - we might have a set of releases like these:

* detection_scheme: original, detected_version: 10.0.32.0, vendor_version: 10.0.32.68, status: maybe_vulnerable
* detection_scheme: original, detected_version: 10.0.32.0, vendor_version: 10.0.32.72, status: maybe_vulnerable

* detection_scheme: version_available, detected_version: 10.0.32.68, vendor_version: 10.0.32.68, status: vulnerable
* detection_scheme: version_available, detected_version: 10.0.32.72, vendor_version: 10.0.32.72, status: latest

Comment 8

[Lloyd Trevor Hilaiel]

(In reply to comment #6)

Yo Austin,

Thanks for all of the context.  As a representative of a plugin vendor I'd love to help.  All you're doing is providing yet another vector to help keep our software up to date and that's an awesome goal we'd like to support.  Cross browser support good too, bravo (I suggest http://parrotsgroomed.org)

Back this bug, I know that we were not correctly building our OSX plugin to put version in the manifest so that ffx could glean it.  Here's a change I recently made to fix that:

http://github.com/browserplus/platform/commit/13ca37dad65a2534b7c2900f5bacb6c417f439fe

Along these lines, in addition to smart heuristics to figure all this out I'd suggest that you levy some suggestions onto plugin vendors like us so we can provide you with structured information regarding versioning, where to send users for updates, etc.  This could be guidelines about how we build our plugins or a web service api we should provide to you, or both.  Am I ignorant and something like this already exists?

waaaay off topic,
lloyd

Comment 9

[Austin King [:ozten]]

(In reply to comment #7)
This sounds great.

Perfidies will send detection_scheme, server will respond with the appropriate
version and the vendor version, perfidies will do version matching as it does
currently.

Perfidies will use the best version detection available based on the browser
and have a mapping of detection schemes: original, version_available (Fx 3.6,
future browsers), extra_crispy)

Comment 10

[Austin King [:ozten]]

(In reply to comment #8)
I'll add you to our vendor contact list. I'll also email you outside of this bug.

Comment 11

[Austin King [:ozten]]

We met today and our rough plan is to get this onto stage by Thursday 3/12 and Production probably A week or two afterward.

BrowserPlus is looking good in dev environment, sorry for the lag since the last update.

Comment 12

[Lloyd Trevor Hilaiel]

great.  no sweat about the lag.  lag is my middle name, so I deserve it.

fwiw, the changes mentioned in comment #8 are now deployed in production (90% or so), and addtionally we've changed the plugin name to include version number, so that the detection logic should have a bit of an easier time with things.

thanks for the update!

Comment 13

[Austin King [:ozten]]

http://www-trunk.stage.mozilla.com/en-US/plugincheck/ has been updated to use navigator.plugins[id].version.

It has been updated with Lloyd's patch.

It also supports cross-browser plugin detection.

Comment 14

[Stephen Donner [:stephend] Not actively reading bugmail]

Raymond and I are working on testing this, and have a test plan (!) up at https://wiki.mozilla.org/QA/Execution/Web_Testing/PluginCheck, which we'll tweaking as we go along.

Comment 15

[Austin King [:ozten]]

(In reply to comment #12)
@Lloyd can you code review this snippet which only runs for IE:

var browserPlusMime = 'application/x-yahoo-browserplus_2';
    Pfs.$('body').append('<div id="foo"><object id="__browserPlusPluginID" type="' + browserPlusMime + '"></object></div>');    
    var bp = Pfs.$('#foo object').get(0);
    if (bp && bp.Info) {
        var browserPlusVersion = bp.Info().version;
        alterNavigator('BrowserPlus (from Yahoo!)',
                       'BrowserPlus ' + browserPlusVersion,
                       'npybrowserplus_' + browserPlusVersion + '.dll',
                       browserPlusMime);
    }

It is also live on www-trunk.stage.mozilla.com. Thanks!

Comment 16

[Austin King [:ozten]]

(In reply to comment #15)
Please ignore <div id="foo" part :)

Comment 17

[Lloyd Trevor Hilaiel]

(In reply to comment #15)
> (In reply to comment #12)
> @Lloyd can you code review this snippet which only runs for IE:
> 
> var browserPlusMime = 'application/x-yahoo-browserplus_2';
>     Pfs.$('body').append('<div id="foo"><object id="__browserPlusPluginID"
> type="' + browserPlusMime + '"></object></div>');    
>     var bp = Pfs.$('#foo object').get(0);
>     if (bp && bp.Info) {
>         var browserPlusVersion = bp.Info().version;
>         alterNavigator('BrowserPlus (from Yahoo!)',
>                        'BrowserPlus ' + browserPlusVersion,
>                        'npybrowserplus_' + browserPlusVersion + '.dll',
>                        browserPlusMime);
>     }
> 
> It is also live on www-trunk.stage.mozilla.com. Thanks!

This code looks fine to me.  I think in some rare partially install scenarios it's possible for Info() to throw, but that's more a feature of IE than of our control.

I wouldn't change a thing!

very best,
lloyd

Comment 18

[James May [:fowl2]]

Silverlight's version doesn't seem to be detected on my system in firefox, despite being able to be seen in IE.

http://img197.imageshack.us/i/plugincheckie.png/
http://img696.imageshack.us/i/plugincheckfirefox.png/

Win7 x64 Firefox 3.6, IE 8

Comment 19

[Austin King [:ozten]]

(In reply to comment #18)
@Stephen can you reproduce on Windows 7?

Thanks James! We should file a new bug to track this.

Comment 20

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #19)
> (In reply to comment #18)
> @Stephen can you reproduce on Windows 7?
> 
> Thanks James! We should file a new bug to track this.

I can reproduce, and filed bug 552249.

Comment 21

[EstherDavid Steffens]

(In reply to comment #13)
> http://www-trunk.stage.mozilla.com/en-US/plugincheck/ has been updated to use
> navigator.plugins[id].version.

Unfortunately, "RealPlayer Version Plugin" has now gone missing when I tested that on Win XP/SP3 FF 3.6.3. New PluginCheck page reports "Unable To Detect Plugin Version" for "RealPlayer Version Plugin", but that plugin *is* detected correctly by the current production PluginCheck page.

Not exactly sure where/how to report this possible regression failure, so I'm adding this comment to both Bug 546727 and Bug 522585, in case this hasn't already been noticed/reported.

Comment 22

[Austin King [:ozten]]

(In reply to comment #21)
@EstherD - Thanks for the report. Can you try www-trunk again, I tweaked the database.

Comment 23

[James May [:fowl2]]

I'm getting the same thing.

http://img21.yfrog.com/img21/9573/plugincheck.png