45698 - [PIDEV] XPCOM component registry should include keys to distinguish new plug-ins from ordinary XPCOM components

Status: VERIFIED FIXED

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

Description

[ekrock's old account (dead)]

To enable high-performance loading of plug-ins and the population of the DOM 
navigator.plugins array at startup (without having to scan every XPCOM component 
to determine whether it's a plug-in), at installation, new plug-ins should 
register themselves in the component registry as new-plugins using registry keys 
TBD by Chris Waterson.

Under this system, Mozilla will create a wrapper for Nav4.x plug-ins at startup 
and create an entry for them in the component registry, so they will have a 
transient entry during runtime. New plug-ins will have explicitly registered 
themselves here at installation and thus have a persistent entry across 
sessions. 

Chris estimates that implementation of this will require one person-week, a 
significant resource hit at this phase in the development cycle. However, 
solving this problem is necessary to deliver a complete, usable Mozilla Plug-in 
API.

Adding [PIDEV] to Summary to flag plug-in API completion bugs that are blocking 
plug-in developers in general (as opposed to the developer of a specific 
plug-in).

Comment 1

[ekrock's old account (dead)]

PDT team: Nominating nsbeta2 (seeking authorization for Chris to check in the 
fix he has ready to go, but not asking that we hold nsbeta2 for this if he 
doesn't get it in the next few days) and nsbeta3 (for which this bug is a 
stopper if we want to have a usable Mozilla Plug-in API in the product and 
backward compatibility with existing content that sniffs using the 
navigator.plugins array). I recognize that we're past 7/17 and that "pulling off 
the wire" is the criterion for true "nsbeta2 stopper" status. However, this bug 
blocks 37522 which is nsbeta2+ approved. Both these bugs are key to achieving 
our goal of N6 PR2 being a release against which plug-in vendors can develop 
and test working Mozilla Plug-in API-based plug-ins. Please permit Chris to 
check in if he has a reviewed fix believed to be low risk.

Comment 2

[ekrock's old account (dead)]

*** Bug 37504 has been marked as a duplicate of this bug. ***

Comment 3

[sean echevarria]

*** Bug 44614 has been marked as a duplicate of this bug. ***

Comment 4

[Jay Patel [:jay]]

Putting on [nsbeta2-] radar. Not critical to beta2. 

Comment 5

[ekrock's old account (dead)]

Clearing [nsbeta2-] to trigger re-evaluation. I need to clarify my comments 
here. This is not some cool new whiz-bang end user feature that is a "nice to 
have" and OK to check-in whenever. The lack of this functionality is blocking 
our plug-in partners like RealNetworks, Macromedia, and others from being able 
to upgrade their plug-ins that *must* be done in time for FCS. They cannot move 
forward until we unblock them. One of the original key goals for N6 PR2 in the 
beta2 criteria was to be feature-complete for the Plug-in API to enable plug-in 
vendors to write to it and to test against it. If we do not check in this 
functionality, we will fail to meet that goal. (Basically, I was too 
accommodating of the "ship at any cost" mentality in my previous comments; we 
need to draw a line on functionality on this one.) The bottom line is that we 
need to deliver a product to our developers that they can write to so that they 
are able to move forward quickly and find by running their upgraded plug-in on 
PR2 with widespread testing the other Plug-in API bugs we don't know about which 
will also have to be fixed during nsbeta3 and for rtm.

Bottom line: this *is* a "pull it off the wire" issue because of the external 
partner code development dependency and the fact that not fixing this bug 
is preventing our plug-in partners from uncovering other bugs we don't 
know about yet. Please mark [nsbeta2+] and permit the check-in. Thanks!

Comment 6

[leger]

Per today's PDT mtg, setting to [nsbeta2+]

Comment 7

[Chris Waterson]

Attachment: PLUGIN_LOVE_2000_07_17_BRANCH, as a patch.

Comment 8

[Chris Waterson]

Here are the salient changes:

- Add RegisterPlugin() and UnregisterPlugin() methods to nsIPluginManager. 
Added at the end of the vtable so as not to disturb existing binaries.

- Add implementations of these methods to nsPluginHostImpl. RegisterPlugin() 
adds persistent registry entries under nsIRegistry::Common/software/plugins, 
one subtree per plugin CID. That subtree holds the plugin's "name" and 
"description" attributes. Beneath that subtree are further subtrees, one per 
MIME type that the plugin supports. Each of *those* subtrees has a "mimetype", 
"description", and "extension" value.

- UnregisterPlugin() removes the plugin's subtree from the registry.

- Add XPCOM plugins to the plugin datastructurs when plugin manager is started 
from nsIPluginManager::LoadPlugins().

- Refactor code shared between libgklayout.so and libgkplugin.so. Specifically, 
move nsPluginViewer out of layout and into plugin DLL. Implement plugin 
doc-loader factory, separate from layout's DLF.

- Update sample plugin to reflect API changes; uses nsIModule, no longer 
requires nsIPlugin.

Comment 9

[Chris Waterson]

Also,

- Made libgkplugin.so into an XPCOM module. I have changes to 
mozilla:build:mac:NGLayoutBuildList.pm (not in the above patch) to accomodate 
for that.

Comment 10

[Chris Waterson]

Attachment: clean patch (without merge conflicts. duh.)

Comment 11

[Chris Waterson]

Attachment: new file, save as mozilla/modules/plugin/nglsrc/nsPluginModule.cpp

Comment 12

[Chris Waterson]

Please ignore the first patch: it had merge conflicts. The second patch fixes
that, as well as some build ordering issues that are introduced (modules/plugin
now depends on GFX because nsPluginViewer now lives there). Finally, I included
nsPluginModule.cpp, a new file.

Comment 13

[Chris Waterson]

And look, pierre phaneuf has already contributed to it!

Comment 14

[Chris Waterson]

Attachment: One more try. This one has no merge conflicts. I swear.

Comment 15

[sean echevarria]

One comment about the patch so far.  Rather than recording the plugins leafname 
in the nsPluginTag struct can we record the whole path?

The is where the leafname is pulled out of nsIFile in nsPluginHostImpl.cpp:
      if (NS_SUCCEEDED(rv)) {
        file->GetLeafName(getter_Copies(filename));
      }

If you display installed plugins using this link 
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=9156 you will see the 
exact location of the installed plugin for 4x plugins but not for xpcom plugins.

Comment 16

[sean echevarria]

One reason you want to see the whole path (as recorded in the registry) is that 
on windows, if you want to unregister a plugin using regxpcom, you have to 
match the case of the file path and name as it was originally registered.

Comment 17

[Chris Waterson]

sean: change "GetLeafName()" to "GetPath()". Does that work for you?

Comment 18

[sean echevarria]

Yep - GetPath() does the trick.

Comment 19

[Chris Waterson]

Attachment: patch that incorporates feedback from sean & andrei

Comment 20

[Chris Waterson]

Attachment: save as mozilla/modules/plugin/nglsrc/nsPluginDocLoaderFactory.h

Comment 21

[Chris Waterson]

Attachment: save as mozilla/modules/plugin/nglsrc/nsPluginDocLoaderFactory.cpp

Comment 22

[Chris Waterson]

Attachment: save as mozilla/modules/plugin/nglsrc/nsPluginViewer.h

Comment 23

[Chris Waterson]

Updated patch to include comments from av & sean; attach new files.

Comment 24

[Chris Waterson]

checked in, r=av

Comment 25

[sean echevarria]

verified

Comment 26

[ekrock's old account (dead)]

*** Bug 18641 has been marked as a duplicate of this bug. ***