37522 - JavaScript plugin object always returns null for description

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect, P3)

Description

[rusty.lynch]

JavaScript plugin object always returns null for description.  The value 
for the description should be coming from GetValue with the variable set to
NPPVpluginDescriptionString.  It looks like GetValue is never called.

This bug results in disabling Flash on a lot of major websites that use the
description string to determine the Flash version.  These site will usually
assume that the Flash plugin isn't installed.

Comment 1

[rusty.lynch]

I just looked back on this bug today and decided to try and wrap this up
(since it is quickly going to be a pain in my side when various web pages
determine the browser doesn't have a give plugin because JavaScript doesn't
see what it expects in navigator.plugins.)

The reason the description property for any plugin is null is that the UNIX
implementation of GetPluginInfo() doesn't bother setting it.  That's an easy
fix.  The problem is that this is just one of many fixes that need to be made
to nsPluginsDIRUnix.cpp after we have some direction on where plugins should
reside, who should be adding them to the plugin host's list of plugins, when
should this happen...

So basicly, we need bug #37504 "Linux XPCom plugin registration not clearly
defined" to be closed.  If I can get #37504 closed out, then I will volunteer
to make the implementation match the expectations.

(I'm adding nsbeta2 to the keywords in an attempt to get this on the radar.
If that's not the correct procedure then let me know.)

Comment 2

[leger]

Putting on [NEED INFO] to ask ekrock about this.

Comment 3

[ekrock's old account (dead)]

This is a definite, definite nsbeta2 stopper. In many cases, if this isn't 
fixed, content sites sniffing for plug-ins won't sniff successfully, so the 
plug-in content won't get run, so the plug-in developers won't be able to 
successfully test to see if their upgraded Mozilla plug-ins are working 
correctly. Strongly recommend [nsbeta2+] for this bug.

Rusty, many thanks for flagging this. Please nominate the other related plug-in 
bugs you mentioned as nsbeta2 by marking nsbeta2 in the keyword field. (That's 
the right approach.) I'm nominating bug 37504 as nsbeta2 right now since this 
bug is blocked on it.

Comment 4

[leger]

Putting on [nsbeta2+] radar for beta2 fix. 

Comment 5

[av (gone)]

Reassigning as per agreement. Chris, this one could be a reason for 35351.

Comment 6

[Chris Waterson]

Attachment: test case

Comment 7

[Chris Waterson]

There are some fairly serious problems here with the way that the plugin 
initialization code was written. Specifically, the intent was to use the 
ns4xPlugin class to "wrap" old 4.x-style plugins, and to use the new nsIPlugin 
APIs to manage plugin instantiation. Trying to decide now if it's best to just 
continue the hackery (in which case, none of the new nsIPlugin APIs will work), 
or to dig in and fix this the right way. Stay tuned.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: proposed fix

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The fix is to

1. implement ns4xPlugin::GetMIMEDescription() and ns4xPlugin::GetValue()

2. alter nsPluginsDirUNIX to instantiate an ns4xPlugin (or a bogo-"new style"
plugin), and then call these routines to pull out the plugin info.

Although in the long run, we probably won't need to worry about nsIPlugin
implementors that live in the plugins directory (these'll all be XPCOM
components), in the short term, this should ensure that Java etc. doesn't break.

Anyone care to review?

Comment 10

[Chris Waterson]

Ok, so those changes were really submitted by waterson. dbaron is the ghost in 
my Linux machine.

Comment 11

[av (gone)]

I'll take a look first thing tomorrow. Thanks, Chris.

Comment 12

[Chris Waterson]

fix checked in, r=av. had to modify the patch a bit to fix places I'd missed in 
#ifdef'd platform code.

Comment 13

[shrirang khanzode]

verified with build (2000072408)