Closed Bug 1038685 Opened 10 years ago Closed 2 years ago

Some plugins don`t appear in plugincheck website even though they are installed and are seen in plugins_list.json

Categories

(Websites :: plugins.mozilla.org, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: bmaris, Unassigned)

References

Details

Attachments

(1 file)

STR:

1. Open Firefox 31.0RC
2. Install VLC plugin on windows or linux.
3. After the install open https://www.mozilla.org/en-US/plugincheck/

Expected results: VLC plugins appears in plugincheck since it shows up in https://plugins.mozilla.org/en-us/plugins_list.json

Actual results: VLC plugins does not appears in plugincheck

Ubuntu:
VLC Multimedia Plugin (compatible Videos 3.10.1)
File: libtotem-cone-plugin.so
Path: /usr/lib/mozilla/plugins/libtotem-cone-plugin.so
Version:
State: Enabled
The Videos 3.10.1 plugin handles video and audio streams.

Windows:
VLC Web Plugin
File: npvlc.dll
Path: C:\Program Files (x86)\VideoLAN\VLC\npvlc.dll
Version: 2.1.3.0
State: Enabled
VLC media player Web Plugin 2.1.3
Plugin Check's list of known plugins only knows about the VLC plugin named "VLC Web Plugin", so I'm not sure why Plugin Check doesn't at least see Windows' "VLC Web Plugin".

https://plugins.mozilla.org/en-us/plugins_list.json
There is also the "gnome-totem" entry, which could match the first entry? I'm not entirely sure how that plugins_list.json is interpreted.

Bogdan, what about the issue with the RealPlayer plugin you were mentioning?
(In reply to Georg Fritzsche [:gfritzsche] [away July 10-14] from comment #2)
> 
> Bogdan, what about the issue with the RealPlayer plugin you were mentioning?

Yes, sorry I was in a hurry yesterday and forgot to mention RealPlayer.
Same story with the RealPlayer plugins though I`m not sure if those are the same plugins that show up in plugins_list.json.

RealPlayer(tm) G2 LiveConnect-Enabled Plug-In (32-bit)

    File: nppl3260.dll
    Path: C:\Program Files (x86)\Real\RealPlayer\Netscape6\nppl3260.dll
    Version: 17.0.11.0
    State: Enabled
    RealPlayer(tm) LiveConnect-Enabled Plug-In

RealPlayer Download Plugin

    File: nprpplugin.dll
    Path: C:\Program Files (x86)\Real\RealPlayer\Netscape6\nprpplugin.dll
    Version: 17.0.11.0
    State: Enabled
    RealPlayer Download Plugin

RealPlayer Video Downloader for HTML5 (32-bit)

    File: nprndlhtml5videoshim.dll
    Path: C:\ProgramData\RealNetworks\RealDownloader\BrowserPlugins\MozillaPlugins\nprndlhtml5videoshim.dll
    Version: 17.0.11.0
    State: Enabled
    This plug-in enables downloading of HTML5 videos

RealPlayer Video Downloader for PepperFlash (32-bit)

    File: nprndlpepperflashvideoshim.dll
    Path: C:\ProgramData\RealNetworks\RealDownloader\BrowserPlugins\MozillaPlugins\nprndlpepperflashvideoshim.dll
    Version: 17.0.11.0
    State: Enabled
    This plug-in enables downloading of Flash videos

RealPlayer Video Downloader (32-bit) 

    File: nprndlchromebrowserrecordext.dll
    Path: C:\ProgramData\RealNetworks\RealDownloader\BrowserPlugins\MozillaPlugins\nprndlchromebrowserrecordext.dll
    Version: 17.0.11.0
    State: Enabled
    This plug-in enables downloading with the Download This Video button
Thanks for all the info everyone, I am going to set up some test environments to reproduce these issues and see what is causing this problem.
Adding here information from
Bug 1020133 "Improve Adobe Acrobat plugin reporting"

Convention:

I am using single quotes for slang / imprecise language.
I am using double quotes (") for direct quotations,
as well as the normal bugzilla quote,
> This is an example of a quotation from another comment. 

Assumptions:

1. You have read bug 956905 comment # 148
    This includes
      * Short History
      * To Do - before 'plugincheck for RELEASE' uses the 'JSON list'
      * Notes on Testing

2. Remember,
   'plugincheck using enumeration' requires
   the setting "plugins.enumerable_names" set to "*", the default.
   Release (currently Fx 32.0.1) does 'plugincheck using enumeration'.

   To verify that
   'plugincheck without enumeration - uses the JSON List'
   is not using ANY enumeration
   use "about:config" to change "plugins.enumerable_names" set to "" (empty string)

   Beta+ (Fx 33+) does 'plugincheck without enumeration - uses the JSON List'.
   You can spoof the UA to Fx 33 to test using the 'JSON List'[1].


*This* bug is listed in the 'To Do' section of bug 956905 comment # 148.
> To Do - before 'plugincheck for RELEASE' uses the JSON list.


Bug 1020133 "Improve Adobe Acrobat plugin reporting" is another
bug which is blocking 'plugincheck for RELEASE uses the JSON List'.

That bug is long.
There have been many duplicates of it in addition to the ones 
'that are official, in bugzilla, Duplicates'.

Since May 2014, each time a new version of Firefox is released,
a Bedrock bug has to be opened to 'bump the version test', at plugincheck,
so that only Beta+ uses the JSON List and the 'new Firefox release'
continues to use enumeration of the visiting browser's plugins.

In bug 1020133
Dan Pernokis has attached several very informative screenshots:

https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8489041
2014-09-13 using Fx 32.0.1 (release) [from bug 1020133 comment # 38]
Shows "about:addons", the Plugins 'Tab'.
Dan has 15 plugins, including "VLC Web Plugin 2.1.0.0".

https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8489040
2014-09-13 using Fx 32.0.1 (release) [from bug 1020133 comment # 37]
Shows a 'plugincheck using enumeration'.

Here we can see:

A. Flash "vulnerable" - Dan knew this - it was a deliberate test.

B. 7 "unknown" plugins.  In my opinion, this is 'useful to know'.
  I think it is clear that the user needs to use another method
  of assessing these "unknown" plugins, 'plugincheck' is not
  assessing them (to tell the visitor about their Status:
  "Up to Date" or "vulnerable" etc).
      See bug 965812 for more on this point.

  Plugincheck is also, since bug 1017483, giving helpful information
  on the version 'detected', *including* for "vulnerable" plugins.

C. 6 known and "Up to Date" plugins (including "VLC Web Plugin" version "2.1.0.0").
  Very useful.
  Only 14 (not 15) reported.
    This is another issue:
    'Adobe Acrobat', the real Acrobat that can write PDF files,
    called "Adobe Acrobat 9.5.5.316"
    was 'not detected', not even "unknown"!
    See bug 1020133 comment # 41 onwards.

I asked Dan to try 'plugincheck without enumeration - uses the JSON List',
by spoofing the UA.  I thought the 'JSON List' might have enough data
to assess Silverlight.

As the screenshot (above), shows, there were '7 known' plugins:
Flash was "vulnerable" and 6 were "Up to Date".

I expected, when Dan tested, that
'plugincheck without enumeration - uses the JSON List'
would find and report:
A. The WRONG result for Adobe Reader (bug 1020133 is mainly about this).
B. Flash to be "vulnerable".
C. 5 others to be "Up to Date".
Making a total of 7 plugins reported.

See
https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8489164
2014-09-15 Dan spoofed the UA to Fx 33 [from bug 1020133 comment # 43]
'new plugincheck - uses the JSON List'
Only 6 were reported, "VLC Web Plugin" was 'missing'.

*This* bug is about VLC (and also RealPlayer - comment # 3).


Copied from bug 1020133 comment # 45 (with some edits)

"VLC Web Plugin" version "2.1.0.0" is NOT reported.

Why?
Look at the 'JSON List'.[2]

https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8487601
> 4937      'videolan-vlc': {
> 4938        'display_name': 'VLC Multimedia Plug-in',
> 4939        'description': '',
> 4940        'versions': {
> 4941          'all': {
> 4942            'latest': [
> 4943              {
> 4944                'status': 'latest',
> 4945                'filename': 'npvlc.dll',
> 4946                'version': '2.1.0.0',
> 4947                'detected_version': '2.1.0.0',
> 4948                'detection_type': '*',
> 4949                'os_name': '*',
> 4950                'platform': {
> 4951                  'app_id': '*',
> 4952                  'app_release': '*',
> 4953                  'app_version': '*',
> 4954                  'locale': '*'
> 4955                }
> 4956              }
> 4957            ],
> 4958            'vulnerable': [
> 4959              {
> 4960                'status': 'vulnerable',
> 4961                'name': 'VLC Web Plugin',
> 4962                'vulnerability_description': 'Vendor information',
> 4963                'vulnerability_url': 'http://www.videolan.org/security/sa1302.html',
> 4964                'filename': 'npvlc.dll',
> 4965                'version': '2.0.2.0',
> 4966                'detected_version': '2.0.2.0',
> 4967                'detection_type': '*',
> 4968                'os_name': '*',
> 4969                'platform': {
> 4970                  'app_id': '*',
> 4971                  'app_release': '*',
> 4972                  'app_version': '*',
> 4973                  'locale': '*'
> 4974                }
> 4975              }
> 4976            ]
> 4977          },
> 4978          'win': {
> 4979            'latest': [
> 4980            ],
> 4981            'vulnerable': [
> 4982            ]
> 4983          },
> 4984          'mac': {
> 4985            'latest': [
> 4986            ],
> 4987            'vulnerable': [
> 4988            ]
> 4989          },
> 4990          'lin': {
> 4991            'latest': [
> 4992            ],
> 4993            'vulnerable': [
> 4994            ]
> 4995          }
> 4996        },

I made my 'quick prediction' of "only 7 of your plugins will be reported" based on
'I know there will be no "unknown" so I expect a MAXIMUM of 7' without checking either
the 'JSON List' or the 'list of plugins' that Schalk was going to track.

  See:
  Schalk Neethling, on 2014-02-23, in bug 956905 comment # 75
  which listed 37 plugins.  These include:
  > string(22) "VLC Multimedia Plug-in"  

So, the 'inability to detect and report on the "VLC Multimedia Plug-in"
in the 'new plugincheck - uses the JSON List'
is NOT because there is no "VLC Multimedia Plug-in" data in the JSON List.

Note:
> 4978          'win': {
to
> 4996        },
looks 'empty'.  

Schalk, I have not researched the "VLC Multimedia Plug-in".
I speculate that the web site 'detection code' might need some
data in the relevant 'OS section'.

I don't know which OSs can use the "VLC Multimedia Plug-in".

<snip>

Remember, the scope of plugincheck is to 'help users stay safe by not using
old, vulnerable, plugins'.  It can't test everything.

To avoid 'scope creep' it would be good to test
ALL the 37 plugins listed in bug 956905 comment # 75.

Once ALL of them are 'reported correctly' on the 'new plugincheck - uses the JSON List'
I would then advocate that ESR Versions are added, e.g. ESR Flash.

See bug 956905 comment # 148 for more 'To Do' items.
Some of these 'To Do' items could be done in parallel with this bug, possibly by 'QA folk'.

DJ-Leith



Dan Pernokis, in bug 1020133 comment # 46, added:

> How does FF know which plugins it has?  I see Registry Entries with
> everything I have, one entry per plugin (plus two obsolete VLC entries),
> and each entry has a path to the plugin, its description, version ID, etc.  
> But does it maintain its own list too?  I see only a few files (far from 
> all) in the FF plugins folder.  There are also oddities (different 
> versions, etc) among the list of plugins and the two plugin checks 
> (old and new).
> 
> Regarding VLC:
> 
> Where does the VLC "2.1.0.0" come from???  I'm actually running 2.1.2 -- and
> the registry has entries for 2.0.8, 2.1.1, and 2.1.2 -- no "2.1.0.0" which
> is what MORE calls it too (along with video type detail that it has to dig
> from somewhere).

> BACKGROUND on VLC:  See my Bug 915323 -- there was a raging battle at the
> time between VLC and MOZ on how plugins were being checked back then.  
> In this case, the plugin 2.0.6 was safe but the VLC 2.0.6 library had issues.  
> Updating upgraded the library to 2.0.8, but not the plugin which remained 
> at 2.0.6.  All safe, but FF still said "vulnerable".   Could be that MOZ 
> people at the time just decided let FF ignore checking on it because there
> was no way to validate what the user really had.  (You could only look so 
> far -- to the plugin, not to the library itself.)  So now, today, with 
> 2.1.2, is this perhaps the same situation that the plugin version lags the 
> library again, so the check just ignores it altogether?  It does not make 
> logical sense to me that the two should be out-of-sync.


See also bug 992583 "plugin check incorrectly identifies linux vlc and gecko-mediaplayer as vulnerable 



[1]
(from bug 1020133 comment # 41)
On Windows 7, the 'UA spoof for Beta' is:
user_pref("general.useragent.override", "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0)
Gecko/20100101 Firefox/33");

You have to "about:config", make a new String called "general.useragent.override"
then make this string the UA, e.g. "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0)
Gecko/20100101 Firefox/33".

Once you have the "general.useragent.override" setting you can edit the
"rv:33.0" and "/33" to any version you want to 'pretend to be'.


[2]
The 'JSON List' cited was attached to bug 1020133 comment # 33.
https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8487601
I called the file
"Plugincheck-Fx-34-build-aa315da-with-line-numbers-2014-09-10.txt".

So, it was very similar to the 'JSON List' that I could have
accessed *direct* from LIVE.  I wanted to access it indirectly
to show how 'plugincheck' was giving the WRONG result
for Adobe Reader, when using the 'JSON List'
vs
an accurate result, when using the old method (by enumeration),
which used some of the PFS code
(see bug 1020133 comment # 30 onwards).

Date: 2014-09-10
The 'live version of the JSON List' may now have different data.

I added line numbers, and kept the '8 lines of Scratchpad comment',
so that you could compare the 'LIVE JSON List' with the data
as at Date: 2014-09-10.

Anybody can get a 'live version of the JSON List',
like the one linked above,
direct from Mozilla, as I described in bug 1020133 comment # 33:

> So, the 'JSON List' is here:
> https://plugins.mozilla.org/en-us/plugins_list.json
> 
> The actual 'line numbers as seen in Scratchpad' may now
> be different.
> 
> Steps to read the JSON:
> 1. browse to https://plugins.mozilla.org/en-us/plugins_list.json
> 2. click once in the JSON and then <ctrl>+<a> (to select all)
> 3. <ctrl>+<c> (to copy)
> 4. <shift>+<F4> to open Scratchpad
>  (or use the mouse to Firefox, Tools, Web Developer, Scratchpad)
> 
> 5. click at the 'line 9', and <ctrl>+<v> (paste).
> You will have one *huge* line.
> 
> 6. click "Pretty Print" button, and you will have the JSON in a much
> more 'human readable' form (with line numbers).
> 
> Like the 
> "Plugincheck-Fx-34-build-aa315da-with-line-numbers-2014-09-10.txt"
> there are 5428 lines in the 'JSON List' (including the 8 lines of comment at the top).


DJ-Leith
Dan,
have you found "npvlc.dll"?
> 4945                'filename': 'npvlc.dll',

See comment # 0.
Bogdan Maris, QA [:bogdan_maris] found:

> Windows:
> VLC Web Plugin
> File: npvlc.dll
> Path: C:\Program Files (x86)\VideoLAN\VLC\npvlc.dll
> Version: 2.1.3.0
> State: Enabled
> VLC media player Web Plugin 2.1.3

Use "about:plugins" on *both* profiles, to find the path to the File.
Do you get the same results, using "about:plugins", for both profiles?

http://kb.mozillazine.org/About:plugins
> In some cases, about:plugins may display outdated information, even after a restart.
> To refresh the list, ...

Most plugins are 'machine wide' but it is possible for "about:plugins"
to give misleading information and it is also possible
to have 'profile errors'.
Often, when trying to diagnose an issue, using a fresh profile is very useful.

Copied from bug 1020133 comment # 47 to give an example,
finding the metadata for the 'Adobe Reader' plugin
(Adobe use "Adobe Acrobat" in the metadata).


My
"C:\Program Files (x86)\Adobe\Reader 11.0\Reader\browser\nppdf32.dll"
Has, using Windows Explorer, properties, "Details" Tab,

> File description    Adobe PDF Plug-In For Firefox and Nets...
> Type                Application extension
> File version        11.0.8.4 <== both methods of 'plugincheck website detection',
                                        by enumeration and 'using the JSON List'
                                        report this as "11.0.8.4"
> Product name        Adobe Acrobat   [this choice of name is Adobe's choice]
> Product version     11.0.8.4        [same as "File version"]
> Copyright           Copyright 2000-2012 Adobe Systems Inc...
> Size                222 KB
> Date modified       05/08/2014 18:20 (UK date, i.e. 5th August 2014 6:20 pm) 
> Language            English (United States)  [common for software in UK to have US version]
> Original filename   NPPDF32.DLL 

Dan Pernokis said (now in comment # 5):
> How does FF know which plugins it has?  I see Registry Entries with
> everything I have, one entry per plugin (plus two obsolete VLC entries),
> and each entry has a path to the plugin, its description, version ID, etc.
The 'plugincheck service' will not use the Windows Registry.
Indeed, part of the motivation to STOP enumeration of plugins,
is to be 'less intrusive' in the Firefox User's computer.

DJ-Leith
@DJ-Leith:   Comment #6:  Did I find npvlc.dll?

FYI, I have and follow standard Windows 7 folder structure & conventions.

I found npvlc.dll in the "C:\ProgramFiles\VideoLAN\VLC" folder.
(It was not present in the FF folders -- only Adobe and QT plugins are there.)
There was also a .manifest file for it, with verbiage confirming that npvlc.dll is the FF plugin.

-dan-
Dan,
sorry - my question was too vague.

File metadata for your "VLC Web Plugin".

I was thinking that 'the Plugincheck Service' might be using some of the
'file metadata' to produce the version "2.1.0.0" for the "VLC Web Plugin".

So, if we can find the 'field' that has "2.1.0.0" it might be useful to
document this.


Recall that, what we have been calling the 'Adobe Reader plugin',
on my Windows 7, 64bit OS, PC - the file is "nppdf32.dll".

"C:\Program Files (x86)\Adobe\Reader 11.0\Reader\browser\nppdf32.dll"

It was reported at plugincheck as version "11.0.8.4",
"about:plugins" also reported it as version "11.0.8.4" and
Windows Explorer reported it as version "11.0.8.4" as well: all three agree.


File metadata for "nppdf32.dll".

My
"C:\Program Files (x86)\Adobe\Reader 11.0\Reader\browser\nppdf32.dll"
Has, using Windows Explorer, properties, "Details" Tab,

> File description    Adobe PDF Plug-In For Firefox and Nets...
> Type                Application extension
> File version        11.0.8.4 <== both methods of 'plugincheck website detection',
                                        by enumeration and 'using the JSON List'
                                        report this as "11.0.8.4"
> Product name        Adobe Acrobat   [this choice of name is Adobe's choice]
> Product version     11.0.8.4        [same as "File version"]
> Copyright           Copyright 2000-2012 Adobe Systems Inc...
> Size                222 KB
> Date modified       05/08/2014 18:20 (UK date, i.e. 5th August 2014 6:20 pm) 
> Language            English (United States)  [common for software in UK to have US version]
> Original filename   NPPDF32.DLL


"VLC Web Plugin"

Your screenshot
https://bug1020133.bugzilla.mozilla.org/attachment.cgi?id=8489040
2014-09-13 using Fx 32.0.1 (release) [from bug 1020133 comment # 37]

So plugincheck, using enumeration, shows your "VLC Web Plugin"
as version "2.1.0.0".

Bogdan Maris, QA [:bogdan_maris], on 2014-07-15, in comment # 0, found:

> Windows:
> VLC Web Plugin
> File: npvlc.dll
> Path: C:\Program Files (x86)\VideoLAN\VLC\npvlc.dll
> Version: 2.1.3.0
> State: Enabled
> VLC media player Web Plugin 2.1.3

I think Bogdan used "about:plugins" to provide this data.

Not exactly the same version (it is NOT "2.1.0.0").

You said, in comment # 5:
> Regarding VLC:
> 
> Where does the VLC "2.1.0.0" come from???  I'm actually running 2.1.2 -- and
> the registry has entries for 2.0.8, 2.1.1, and 2.1.2 -- no "2.1.0.0" which
> is what MORE calls it too (along with video type detail that it has to dig
> from somewhere).

I agree,
> Where does the VLC "2.1.0.0" come from???
is a very good question.

A. What does "about:plugins" report for your "VLC Web Plugin"?

B. What properties can you see when you use Windows Explorer?


We saw, with what we have been calling the 'Adobe Reader plugin',
that Adobe have put
> Product name        Adobe Acrobat   [this choice of name is Adobe's choice]

and
> File version        11.0.8.4 <== both methods of 'plugincheck website detection',
                                        by enumeration and 'using the JSON List'
                                        report this as "11.0.8.4"
> Product version     11.0.8.4        [same as "File version"]

into the file metadata of "nppdf32.dll".


DJ-Leith
For DJ-Leith:  VLC plugin for FF (2.1.0.0)

So THIS is where the "2.1.0.0" comes from !!
@DL-Leith:  Your Comment #8 / My screen Comment #9

VLC:
The metadata for npvlc.dll says "2.1.0.0".  So the plugin file's metadata contains the trailing ".0" -- makes sense, so they can build/create and issue several renditions of a file without changing the inherent version ID.

FF about:plugins shows this:
> VLC Web Plugin
>     File: npvlc.dll
>     Path: C:\Program Files\VideoLAN\VLC\npvlc.dll
>     Version: 2.1.0.0
>     State: Enabled
>     VLC media player Web Plugin 2.1.0

My VLC is not current -- mine says 2.1.2 and tells me a new version is available (2.1.5 as of today).  I'm not surprised that Bogdan found 2.1.3 in his.  And based on the following below, I won't be surprised to learn the metadata and about:plugins show it as 2.1.3.x (likely .0).

The trick is my warning about Bug 915323 (quoted above in your Comment #5, from my note in Bug 1020133 Comment #46):  VLC does not keep their plugin and their program library versions in sync, and plugin check cannot tell the difference -- because you could have the exact same perfectly good/clean plugin for two (or more!) different program versions, one/some good and one/some BAD!


ADOBE:
Adobe READER's HELP/ABOUT shows its version as "11.0.08" (note zero eight), and its metadata (AcroRD32.exe) says "11.0.8.4".  The FF plugin (nppdf32.dll) is 11.0.8 on my system, and metadata says "11.0.8.4".  All of this confirms your notes above.  And no surprise then, Acrobat 9.5.5 metadata shows "9.5.5.136".

SILVERLIGHT:
Silverlight's md says "5.1.30514.0", exactly the same as the 'version' shown in the file description.  Note that this description is a literal *within* the file, and in THIS case (Silverlight) the descriptive info contains the trailing ".0" digit.  (The trailers do NOT occur in any of the DLLs I've checked (including Adobe and VLC noted here).

CONCLUSION:
All version info in about:plugins agrees with the respective version and metadata file versions, as far as I see for the plugins I have.  The version info is included in the literal description string (or immediately adjacent to it) within the DLL, for harvesting by anyone who looks (such as HELP/ABOUT, a file/plugin checker like FF, or the plugin's parent/owner/master program itself).


So next... Where does all the MIME type (file extension) info come from?  A list in a file or table?  The registry?  The specific DLLs and plugins?  (This looks like the same info that MORE presents in the FF & TB ADD-ONS manager -- is it something internal to FF & TB?)

-dan-
Dan,
Thanks for confirming that "VLC Web Plugin" has "2.1.0.0" in the 'File Version'
section of the file metadata, as seen in your screenshot
https://bug1038685.bugzilla.mozilla.org/attachment.cgi?id=8491651
Indeed, it is ONLY the 'File Version' field that has "2.1.0.0"

I think "about:plugins"
also finds "Version" by using the 'File Version' part of the file metadata.

I think plugincheck is also reading the same 'File Version' field.

(from comment # 8)
> Recall that, what we have been calling the 'Adobe Reader plugin',
> on my Windows 7, 64bit OS, PC - the file is "nppdf32.dll".
> 
> "C:\Program Files (x86)\Adobe\Reader 11.0\Reader\browser\nppdf32.dll"
> 
> It was reported at plugincheck as version "11.0.8.4",
> "about:plugins" also reported it as version "11.0.8.4" and
> Windows Explorer reported it as version "11.0.8.4" as well: all three agree.


Schalk,

As Dan has reported VLC have in the past, and seem to continue,
to use *different* versions of files (as seen in the metadata)
between the 'main software version' vs 'the plugin'.

Here is one example, from the Forum (that Dan had cited,
and contributed to, in bug 915323).

"Web Plugin 2.0.8 Not Installing Firefox"
https://forum.videolan.org/viewtopic.php?f=14&t=113077


> Re: Web Plugin 2.0.8 Not Installing Firefox
> Post by Voynich Sat Aug 17, 2013 4:51 pm
> 
> Same here.Seems that vlc.exe is version 2.0.8 ,but the web plug-in file, npvlc.dll 
> is the old version 2.0.6. Firefox is saying it is vulnerable and needs to be updated.
> Running Win 7 ultimate 64 and FF 23.0.

So, this is another factor to bear in mind.


The big question, in this bug, is
'Why did plugincheck, without enumeration, using the JSON List'
NOT find the "VLC Web Plugin"?

DJ-Leith
Today the FF33 Plugin Check (from the TOOLS menu) shows my VLC media player Web Plugin 2.1.0 as "vulnerable" and offered an update.  Version 2.1.2 has been current for some time but hasn't shown as out-of-date or vulnerable in FF.  (I just haven't gotten around to updating it yet.)

Now, according to the VideoLAN site, it looks like VLC 2.1.5 is the latest -- but Schalk's test command line...
  http://ossreleasefeed.github.io/Perfidies-of-the-Web/
...doesn't even list VLC at all.

-dan-
(In reply to Dan Pernokis from comment #12)
> Today the FF33 Plugin Check (from the TOOLS menu) shows my VLC media player
> Web Plugin 2.1.0 as "vulnerable" and offered an update.  Version 2.1.2 has
> been current for some time but hasn't shown as out-of-date or vulnerable in
> FF.  (I just haven't gotten around to updating it yet.)
> 
> Now, according to the VideoLAN site, it looks like VLC 2.1.5 is the latest
> -- but Schalk's test command line...
>   http://ossreleasefeed.github.io/Perfidies-of-the-Web/
> ...doesn't even list VLC at all.

If entries are outdated, please file new bugs for them.
Georg, my Comment #12 was posted here for reference -- cloned from Bug 1020133 where we've been tracking current and not-so-current Adobe plugins showing up -- correctly or not -- in the plugin checkers.  VLC is a side issue there (as one that also shows up or not), but here VLC is the star.

So let me correct Comment #12...

We knew this back on 2014-09-18 (my Comment #10):
>> My VLC is not current -- mine says 2.1.2 and tells me a new version is available
>> (2.1.5 as of today). 

This is not simply an 'outdated entry' problem, but an ongoing issue of something not working and currently being worked on:
(1) In the 'standard' plugin check (from the FF TOOLS menu), the VLC hadn't shown as out-of-date or vulnerable.  Now it does.
(2) VLC still does not show AT ALL in Schalk's latest test version of the plugin check.

-dan-

PluginCheck is no longer supported

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: