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?

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?

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

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.

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

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

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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.)

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.)

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).

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 ***

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