44754 - NS_PLUGIN_CID should not exist

Status: VERIFIED WONTFIX

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

Description

[Braden]

CID-in-the-IDL badness aside, I can't think of any reason why NS_PLUGIN_CID (in
nsIPlugin.idl) should exist at all. Each plug-in should have its own CID.

Comment 1

[Warren Harris]

Ignore. We're abandoning the idl stuff.

Comment 2

[Braden]

Reopening. nsIPlugin.h exhibits the same problem.

Comment 3

[Warren Harris]

Reassigning to av.

Comment 4

[ekrock's old account (dead)]

Not a Netscape 6 RTM blocker. FUTURE. This bug has been marked Future because
the Netscape engineer it is assigned to is overburdened.

Comment 5

[Braden]

It looks like the only thing that this ID is used for is for calling
NSGetFactory; and there it's a placeholder--there's no reason a plugin would
need to check the value of the ID.

NSGetFactory has been deprecated for some time now. Perhaps we could drop-kick
this code that calls it altogether?

Comment 6

[Braden]

Attachment: Proposed patch

Comment 7

[Braden]

This patch removes the definition of NS_PLUGIN_CID, as well as code that calls
NSGetFactory on plugin modules.

Comment 8

[Judson Valeski]

plussing and resetting target milestone. let's rid ourselves of the CID in IDL,
bad practice and exposes us.

Comment 9

[Peter Lubczynski]

Does Real player still function with attachment 28935 [details] [diff] [review]?

Comment 10

[Braden]

Peter: I don't know and I'm not able to test it. I guess you have a reason to
suspect that it wouldn't; does RealPlayer use NSGetFactory?

Comment 11

[Peter Lubczynski]

YES!! Please leave NSGetFactory support for the plugins folder.

Real Player on Windows (and Mac) are both NSGetFactory type plugins. JRE 1.3 is
also. You can test RealPlayer by copying over nppl3260.dll and xpt to the
plugins folder (from the components folder of a NS commercial build full
install) and try playing Netscape radio.

Comment 12

[Braden]

No, I can't. I use Linux. (I can test the OJI plugin; but I think it's moot...)

I thought NSGetFactory had been deprecated for, oh, maybe a couple of *years*
now. I know it had been considered obsolete for some time when I wrote this
patch (a year ago).

Is there a plan for migrating from these obsolete APIs (NSGetFactory and
friends, now the XPCOM plugin API as well)?

I think the requirement for supporting NSGetFactory is a showstopper for fixing
this bug. Since NSGetFactory passes NS_PLUGIN_CID to the plugin, NS_PLUGIN_CID
is part of the interface that Mozilla is apparently committed to supporting.
Recommend WONTFIX.

Comment 13

[Peter Lubczynski]

I also think this bug should be WONTFIX. Let's not touch anything that can break
with the depricated XPCOM plugin API while we still have MAJOR plugins like Real
and Java using nsGetFactory.

Check JRE 1.3's entry points on Linux. I suspect it is doing the same thing as
Windows.

It's bad enough that nsGetFactory support is now disabled for the components
folder and Real is currently broken because that's where its installer had been
dropping the DLL for years. Real also won't fix Real 8's installer so we need to
come up with some installation magic or another creative idea.

The plan now for plugins is to use the old NPAPI but it's too late for some
exsisting plugins. AFAIK, Real has no plans to change from nsGetFactory so we
must keep it alive in the plugins folder. As for Java, Sun's new JRE 1.4 has
switched to using the new nsGetModule but that has been a real mess! That plugin
doesn't install at all with the current trunk because they used unfrozen
interfaces as regexpcom fails.

nsGetFactory seems to have far less complications for XPCOM plugins in the
"plugins" folder than using nsGetModule and needs to stay around for Real.
What's wrong with leaving it as it is?

Comment 14

[Steven Katz]

To further add to the idea the NSGetFactory support not be dropped.  We (the
Java Plugin group at sun) have recieved a request from Netscape (Arun
Ranganathan [e-mail]) that the 1.4.0 plugin not be installed via
regxpcom but that we revert back to using NSGetFactory.  He is saying we must do
in order for Netscape.next/spring/whatever to be bundled with Java 1.4.0.

Maybe you guys should all get together and hash this out.

Comment 15

[Arun Ranganathan]

Dropping NSGetFactory from Plugins folder would be bad because:

1. RealPlayer 8 won't change.
2. JRE dlls won't work; the existing JRE 1.4.0's patronization of regxpcom isn't
working well.  Even if they were to use the regxpcom method, component
uninstallation is awkward.

We're in talks with Real to move away from the deprecated XPCOM API, but this
won't be anytime soon.  Furthermore, for OJI purposes, the plugins folder ought
to have support for NSGetFactory.

Comment 16

[shrirang khanzode]

marking verif, pls reopen stating a reason, Thx!