37504 - [PIDEV][REALPLAYER] XPCom/Legacy Plug-in registration not clearly defined

Status: VERIFIED DUPLICATE of bug 45698

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

Description

[rusty.lynch]

This bug is being filed in response to a lot of confusion on the mozilla-plugins
news group.

Currently, it is unclear what the XPCom/Legacy plugin registration process is.
Should all plug-ins be placed in the 'plugins' directory, or is that set aside
for legacy plug-ins?  If the 'plugins' directory is for all plugins, then
the XPCom registration process needs to look in the 'plugins' directory in
addition to the components directory.  If only legacy plugins belong in the 
'plugins' directory, then the plugins in the components directory need to be
added to the 'plugins' JS object.

Just using the 'plugins' directory would be a lot cleaner. What was the original
design?

Comment 1

[av (gone)]

I think the original design was to keep components in components directory. 
Plugins dir is scanned by the code which checks the version stamps for mime 
type. I don't know what solution would be "cleaner". From the component point of 
view it looks cleaner to have everything xpcom in the comp dir. There is no need 
for a special dir for plugins. Theoretically. We are stuck with it only because 
we want legacy plugins be still in the game. Please correct me if I am missing 
something.

Eric, what is your inclination here?

Comment 2

[Braden]

Also, there are two "components" directories: "bin/components" and
"lib/components". Are these functionally identical?

Comment 3

[ekrock's old account (dead)]

I don't know what the correct answer is (I'll go chat with Andrei to learn 
more), but this is a definite, definite nsbeta2 stopper. Until we resolve this, 
plug-in developers won't know how to write upgraded Mozilla plug-ins. Strongly 
recommend [nsbeta2+] for this bug.

Comment 4

[Patrick C. Beard]

In my opinion, the original design is correct. Plugins are instantiated based on 
MIME type, not via PROGID or CID.

Comment 5

[leger]

Putting on [nsbeta2-] radar.  Will remove minus when have a clear plan of what 
to do.  Renominate when ready.

Comment 6

[sean echevarria]

I'd like to suggest that plugins be installed to the bin/plugins directory for 
performance, nn4x parity and user convenience reasons.  

The way we currently populate the list of installed plugins is by iterating 
thru the files in the nn4x and mozilla plugins directories: doing a name check 
on the file, loading those files that pass and querying the module for mimetype 
information.  Currently the check is limited to plugin modules whose filename 
begins with 'np'.  But it is possible to build and instantiate xpcom plugins 
that do not reside in modules that start with 'np' (xpcom doesn't have module 
name rules like 'components that implement nsIPluginInstance must be 
implemented in modules whose names start with np').

The filename based filter based should be removed (keeping in mind that a 
plugin found in the bin/plugins directory is not necessarily an xpcom plugin - 
a user can easily copy in a nn4x plugin for mozilla use).

If we remove the name based filter, performance will suffer since we would have 
to load every module in the bin/components directory to see if it is an xpcom 
plugin.

Automatic registration that takes place when you first install or run mozilla 
should then process the bin/plugins directory in addition to the bin/components 
directory that it already does (since xpcom plugins do need to be registered).

As a user I'd like to see all my plugins together in one place rather than 
buried in the components dir - easier to disable rogue plugins.

That said, nothing here prevents installation of a stealth plugin (one that is 
not reflected via the navigator.plugins array but can nonetheless be 
instantiated - ie a properly registered xpcom plugin installed in a non-mozilla 
directory).  One could suggest that the plugin discovery code should query the 
registry for components that use NS_INLINE_PLUGIN_PROGID_PREFIX as a prefix to 
their progID (xpcom plugins are instantiated based on a progID of 
NS_INLINE_PLUGIN_PROGID_PREFIX + embed tag specified mimetype).  But that could 
be a performance hit too.

Comment 7

[sean echevarria]

In my last post I raised the idea that we could search the registry based on 
progid prefixes of NS_INLINE_PLUGIN_PROGID_PREFIX to discover xpcom plugins.  

That may not be an option depending on the outcome of 
http://bugzilla.mozilla.org/show_bug.cgi?id=36666.  Adding it as a dependency.

Comment 8

[Andrew Kimpton]

My preference would also be for Plugin binary components to go where users 
expect them to. Into the Plugin directory. It would also make things more 
consistent if the .xpt files could live there too.

I expect most users to have fewer Plugins than Components, and probably be more 
likely to want to delete/disable them too.

Comment 9

[Braden]

XPCOM plug-ins *are* components. As to whether that is a sufficient rationale
for putting them in the same directory as other XPCOM components, I'll pose this
question: Do we anticipate giving other particular kinds of XPCOM components
their own directories?

It's unclear to me at this point whether autoregistration will be part of the
shipping product or not. If it is, I assume it will come with certain rules as
to where XPCOM component DLLs should be placed, and the resolution to this bug
report will likely fall out of that.

But if it is not, then I still think XPCOM plugins should go wherever the rest
of the XPCOM components go. Andrew Klimpton reminds us that under the legacy
plugin registration scheme, users could perform rudimentary management of their
plugins simply be removing them from the plugins directory or renaming them.
While we probably want this to continue to be the case for legacy plugins in
Mozilla, I suspect that these techniques would result in orphaned registrations
under the XPCOM scheme. Thus it may be wise to avoid intermingling XPCOM and
legacy plugins in the same directory.

Comment 10

[Andrew Kimpton]

My major concern is for backwards compatiblity/legacy support with existing 
webpages. 99% of Web page authors using the Pulse Plugin make use of the plugins
[] array to detect for the installed plugin (and I suspect the same is true for 
all other plugins). Right now in order to be enumerated in that array 
the .dll/.so must be placed in the Plugins directory, however the .xpt file 
must be in the components directory (since the Pulse Plugin has an exposed 
Javascript interface too). Hopefully autoinstallation/XPInstall can take of 
this 'bifurcation'.

I CAN'T expect the designers to change 100s (if not 1000s) of webpages nor add 
extra complications to new pages in order to establish the presence of a 
required XP Component.

Comment 11

[Braden]

Yes, XPCOM and legacy plugins should both--indistinguishably--appear in that
array, regardless of the outcome here. No argument there. If there isn't one
already, I'd suggest filing a bug on that particular issue, making it dependent
on this one.

Incidentally, I have had some difficulting getting an XPCOM plugin to work when
it is placed somewhere other than the components directory. See bug 29857.

Comment 12

[sean echevarria]

added dependency on 44614 which splits out the 'xpcom plugins missing from the 
navigator plugins js array' issue.

Comment 13

[Nicholas Hart]

I have an additional concern: I simply want my installer to know where to put 
the plugin and .xpt file.

Comment 14

[ekrock's old account (dead)]

Nominating nsbeta3 (as we must get this fixed--it's blocking our plug-in 
partners from upgrading and possibly finding other RTM-blocker bugs with the 
Plug-in API in the process) and marking [REALPLAYER] in Summary as this is 
blocking Real.

I will schedule a meeting for this Friday (when I'm back in the office) to 
discuss this, make a decision, and resolve so we stop blocking our customers 
here. Who else besides Andrei and Warren should I invite at Netscape?

Non-Netscapers: if you'd like to participate in this meeting, please email me 
your phone # ASAP and we'll dial you in.

Comment 15

[ekrock's old account (dead)]

Have scheduled meeting Mon. 11 a.m.-12 noon Pacific time in Knotts Landing to 
discuss bug #37504 and resolve. Invited av, beard, warren, myself on Calendar. 
Please nominate others who should be invited. Anyone who wishes to dial in 
please email me the number you'll be at & we'll dial you in.

Comment 16

[Braden]

Re. beard's comments on 6/7: I disagree *strongly*. Instantiating plugins based
exclusively on the content type is a big design flaw. It would seem to prevent 
the simultaneous installation of multiple plugins for a given content type. That
feature is something IE has had with ActiveX ever since its version 3.0. And in
an XPCOM world where every implementation has a unique identifier, this
limitation is absolutely silly.

I have filed bug 44973 on this issue.

(Unfortunately, I will not be available for the meeting.)

Comment 17

[rusty.lynch]

Going back to the question of how the browser should find plugins, and how could
the user have control over this... I've been wondering if we should maintain
full description of all plug-ins in an XML file.  Part of plug-in registration
would be to add an entry to the file containing all the info that the plug-in
manager would need to know.

I've hacked around with my nsPluginHostImpl.cpp/.h so that a new DOM document is
created from the installed plug-ins XML file in the nsPluginHostImpl
constructor.  Instead of using a platform specific nsPluginDir to find the
plugin libraries, each <Plugin></Plugin> entry fully describes its file path.

I didn't go through and do a complete rewrite since I was just experimenting to
see if this was a workable solution.  Although, after playing around with the
idea I do think it is workable, and I kind of like the idea of being able having
a central control document for all plug-ins.

I'll bring this up in Monday's meeting to see if people think this is a good
solution (to at least part of this bug.)

Comment 18

[rusty.lynch]

Attachment: Here's a hacky patch to see what I was experimenting with. Like I said, it's just me trying out some ideas.

Comment 19

[ekrock's old account (dead)]

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 20

[ekrock's old account (dead)]

Closing this bug as DUP of 45698 because we've now "clearly defined" the loading 
procedure and 45698 covers the implementation of what we'll do for FCS.

We've met and decided what to do. Here are the relevant points from the meeting; 
see the posting to netscape.public.mozilla.plugins for the full meeting writeup.

1) Where should legacy plug-ins be installed?

Legacy plug-ins should be installed in the plugins directory as that's the place 
they are already designed to search for and install themselves into. (status 
quo)

2) Where should XPCOM components be installed?

bin/components (status quo)

3) Where should new plug-ins (plug-ins which are XPCOM components written to the 
Mozilla Plug-in API) be installed?

bin/components, as with other XPCOM components (status quo)

However, 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.

I have opened bug 45698 to track this issue.

7) Will having new plug-ins in the bin/components directory rather than the 
plugins directory make user administration of plug-ins harder?

This concern was raised and discussed. The conclusion was that (1) putting all 
XPCOM components (including those that happen to be new plug-ins) in 
bin/components (or the corresponding local profile components directory) is the 
Right Thing, and (2) well-designed plug-ins should include an Uninstall option 
that eliminates the need for users to directly modify the contents of these 
directories. In this case, user administration of plug-ins becomes a question of 
running the installer to install and running the uninstaller to remove.

ACTION ITEMS:

Implementation of plan:
- Eric Krock - write up and post this summary and file bugs (done)
- Chris Waterson - document the formal spec based on this summary and resulting 
discussion on mozilla newsgroups. Issues to formalize:
  - What keys in the component registry are required to appear as plug-ins?
  - What keys in the component registry are required to be instantiated?
- Pulse Entertainment has a plug-in that registers 3 MIME types and 3 
extensions. Pulse, RealNetworks, and Beatnik will all attempt to upgrade their 
plug-ins to take advantage of these decisions as soon as possible after 
implementation is complete, providing testing of the design.


Points for QA to verify:
- In Navigator 4 it was possible for plug-ins to be dynamically installed at 
runtime (e.g. you hit a page that needs a plug-in, the page detects that you 
don't have it and redirects you to a page to get it, you install the plug-in and 
can return to the original page without restarting the browser). We believe that 
this will also work in Moz/N6, but this point should be confirmed by QA.
- Correct detection of plug-ins in both a shared bin/components directory (in a 
server-side installation on Linux) and the local user profile components 
directory, with the user profile components taking precedence.

See also bug 45697, bug 45699, bug 45701, and bug 45703 for other issues 
discussed at the meeting.

*** This bug has been marked as a duplicate of 45698 ***

Comment 21

[shrirang khanzode]

mass duplicate verifications . For filtering purposes, pls use keywd
"massdupverification"