77151 - disable NSGetFactory support before 1.0

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P2)

Description

[Mike Shaver (:shaver emeritus)]

We need to get NSGetFactory out before the recommended branch point, so that we
don't have to support it post 1.0.  (And we _really_ don't want to support it
post-1.0.)

Comment 1

[Peter Lubczynski]

Nominating nsbeta1

Comment 2

[Mike Shaver (:shaver emeritus)]

This is going to have to move out to 0.9.2: only ducarroz was studly enough to
fix his code, and I'm not going to have time to jihad through the tree fixing
the other cases.

Once my Mozilla-vacation ends, I'll try to rampage across the tree during the
pre-0.9.2 quiet period.

Comment 3

[Mike Shaver (:shaver emeritus)]

Asa just told me that we shipped 0.9.2!  Who knew?

Comment 4

[chris hofmann]

->0.9.5 since we have run out of time

Comment 5

[Mike Shaver (:shaver emeritus)]

I'm going to say 1.0 for this, and let dougt and whoever controls the "nsbeta1"
marker figure out if we need to push it earlier.

Comment 6

[Doug Turner (:dougt)]

Attachment: Removes obsolete NSGetFactory support

I inverted the meaning of OBSOLETE_MODULE_LOADING.  If set, then old style
NSGetFactory code will run.  I think that this is much clearer.

I removed XPCOM_USE_NSGETFACTORY define in favor of OBSOLETE_MODULE_LOADING.
yeah yeah, it isn't a module, but wtf.	Maybe we should just rip out this
support all together...

Comment 7

[Doug Turner (:dougt)]

to me.

Comment 8

[Mike Shaver (:shaver emeritus)]

Comment on attachment 71785 [details] [diff] [review]
Removes obsolete NSGetFactory support

I'd rather just tear it out -- our build system doesn't provide a way to flip
that switch, and someone who really cares about an NSGetFactory module will be
better off writing an nsGetFactoryComponentLoader rather than requiring a
hard-to-detect build setting.

Comment 9

[Suresh Duddi (gone)]

Comment on attachment 71785 [details] [diff] [review]
Removes obsolete NSGetFactory support

r=dp assuming all clients have been weaned out of using NS_GetFactory()

Comment 10

[Patrick C. Beard]

This shouldn't affect plugins, because we use |NSGetFactory| directly in 
our still-born XPCOM plugin API. We must still support this in our code 
because there are plugin binaries in the world that use it (including 2 Java 
OJI plugins that we own ourselves). Here's the place we're using it:

http://lxr.mozilla.org/seamonkey/source/modules/plugin/base/src/
nsPluginHostImpl.cpp#4449

Comment 11

[Xiaobin Lu]

Steve, I think this will be Okay for 1.4, am I right? Please comment here if you
disagree.

Comment 12

[Steven Katz]

This should not be a problem for the 1.4.* builds since:

1) We are capable of connecting to the browser using nsIModule/regxpcom.

2) It sounds like the NSGetFactory scheme will still be available to plugins
(lumps of software that can be found in the plugins directory), just not to
components (lumps of software found in the components directory).

Whatever is eventually adopted as the "new plugin architecture", we really need
consider wheather that is an appropraite scheme to use to provide Java support
to the browser.  In other words, should the Java Plugin actually be a plugin
when it comes to Mozilla/Netscape or should it be something else.

Comment 13

[Doug Turner (:dougt)]

that is a good question to ask, but is orthoganal to this bug.  lets take it off
line.

Comment 14

[Mike Shaver (:shaver emeritus)]

Comment on attachment 71785 [details] [diff] [review]
Removes obsolete NSGetFactory support

a=shaver for 0.9.9.

Leave the #ifdefs in place until we get some bake feedback, and we'll rip out
the old code before 1.0.

Comment 15

[Doug Turner (:dougt)]

Checking in nsNativeComponentLoader.cpp;
/cvsroot/mozilla/xpcom/components/nsNativeComponentLoader.cpp,v  <-- 
nsNativeComponentLoader.cpp
new revision: 1.78; previous revision: 1.77
done

Comment 16

[Arun Ranganathan]

This could be bad, since RealPlayer 8 uses NSGetFactory and in fact breaks on
trunk builds because of this change(e.g. Real installer puts DLL in Components
directory, not Plugins directory).  It really sounds like Real ought to be
evangelized to change by Mozilla 1.0-based clients, but this is going to be very
hard act of evangelism.  Can anyone make Mach-V suggestions?  Here's Peter L's
update to me:

Looks like removing support for NSGetFactory broke Real in the components
folder. Good news is that it works in the plugins folder. 

Comment 17

[Peter Lubczynski]

See bugscape http://bugscape.netscape.com/show_bug.cgi?id=12512

> Can anyone make Mach-V suggestions?

Maybe plugin code could be changed to also scan the "components" folder for
NSGetFactory-type plugins?

Comment 18

[Steven Katz]

WRT #17

Please don't do that.  It would be a disaster for the Java Plugin.

Java can be registered with the browser either by putting it in the "plugins"
directory (we support NSGetFactory) or by regxpcom registration.  We recommend
that people only use regxpcom on the remote location of the plugin file, but
there is nothing to stop them from making a link in the "components" directory
instead (in fact our own Netscape team here at Sun is doing this [against advise]).

Anyway, if the browser did a NSGetFactory scan of the components directory it is
possible that the Java plugin might get registered twice.

Please consider this before hacking up a solution for Real Player.

Comment 19

[Doug Turner (:dougt)]

How about this: Tell the plugin vender to stop putting stuff in the xpcom
component directory and revamp their installer for the "new and improved post
mozilla 1.0 world"

Comment 20

[Peter Lubczynski]

Real will only update the RealOne installer to drop the nsGetFactory plugin into
the "plugins" folder instead.

However, Real will NOT update the Real 8 installer which is the one Netscape is
planning to ship with because it does not hijack Winamp mime types like the new
version. The current plan is to use some installer magic to move the DLL and
release note the fact this breaks the Real 8 uninstaller.