Closed
Bug 37504
Opened 25 years ago
Closed 24 years ago
[PIDEV][REALPLAYER] XPCom/Legacy Plug-in registration not clearly defined
Categories
(Core Graveyard :: Plug-ins, defect, P3)
Tracking
(Not tracked)
People
(Reporter: rusty.lynch, Assigned: serhunt)
References
Details
(Whiteboard: [nsbeta2-])
Attachments
(1 file)
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?
Comment 3•24 years ago
|
||
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.
Keywords: nsbeta2
Comment 4•24 years ago
|
||
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.
Whiteboard: [nsbeta2-]
Comment 6•24 years ago
|
||
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•24 years ago
|
||
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.
Depends on: 36666
Comment 8•24 years ago
|
||
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.
Comment 10•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
added dependency on 44614 which splits out the 'xpcom plugins missing from the
navigator plugins js array' issue.
Comment 13•24 years ago
|
||
I have an additional concern: I simply want my installer to know where to put
the plugin and .xpt file.
Comment 14•24 years ago
|
||
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.
Keywords: nsbeta3
Summary: XPCom/Legacy Plug-in registration not clearly defined → [REALPLAYER] XPCom/Legacy Plug-in registration not clearly defined
Comment 15•24 years ago
|
||
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•24 years ago
|
||
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.)
Depends on: 44973
Reporter | ||
Comment 17•24 years ago
|
||
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.)
Reporter | ||
Comment 18•24 years ago
|
||
Comment 19•24 years ago
|
||
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).
Summary: [REALPLAYER] XPCom/Legacy Plug-in registration not clearly defined → [PIDEV][REALPLAYER] XPCom/Legacy Plug-in registration not clearly defined
Comment 20•24 years ago
|
||
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 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Comment 21•22 years ago
|
||
mass duplicate verifications . For filtering purposes, pls use keywd
"massdupverification"
Status: RESOLVED → VERIFIED
Updated•3 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•