* I'm sending this to the Installer folks for a first look, since the first suggestion for implementation is an XPInstall based solution. Should anyone have further suggestions for a workaround outside of XPInstall scripts, please make them for consideration so that we may re-assign * Current Behavior: 1. Currently, if you install a component, and wish for your newly installed component to refresh itself, you'll have to invoke a signed script from within the context of a (network delived) web page: function doRefresh() { try{ netscape.security.PrivilegeManager.enablePrivilege ('UniversalXPConnect'); Components.manager.autoRegister(0, null); }catch(e){alert("An unexpected error was encountered (" + e + ").");} } 2. Notice that this spawns a XUL based grant | deny dialog box. Note also that the Components.manager.autoregister( _ ) function is out of scope from within an install script (inside a *.xpi zippy). 3. *However* if you restart the browser, it doesn't matter whether you click grant or deny -- the component will still register itself, making the use of UniversalXPConnect moot. Is this a security concern? An explanation of why this is still a valid mechanism or why the security concern is still valid will be useful. Expected Behavior: You can install a component without raising a grant | deny security dialog box, *especially* since the security concern here is moot -- restarting achieves the same objective. Perhaps making the Components.manager.autoRegister( _ ) object in scope in an XPI script might solve the problem, or else some function that's similar. * Test Case: i.) can try the simple plugin (XPCOM component plugin) npsimple.dll in an xpi package ii.) use the navigator.plugins[ _ ] array before and after calls to function Components.manager.autoRegister(0, null) to determine registration. Then, click 'deny' and restart the browser. The plugin gets registered anyway!

I'm new to security, but, it seems to me that as long as the component itself does not get updated from the web, its auto registration despite user denial does not constitute a *security* threat because we would essentially re-register the same component that we registered at browser install time. Mitch, is this too simplistic a view? Please educate me. Thanks!

Talking to Nisheeth's point: If indeed this poses no security risk, then raising a dialog box in the first place is mere lipservice to security. Either 1. A grant | deny dialog box shouldn't be raised for commands of the sort Components.manager.autoRegister(0, null); OR 2. XPInstall should have a mechanism to refresh a component via an xpinstall script (install.js), thus bypassing the whole dialog box issue.

Don't forget that the grant box is only part of the annoyance involved in Components.manager.autoRegister(0, null). You can't even ask for permission to call it if you are not within an isolated signed jar file. Html in signed jars are slow to load, a hassle to maintain (they don't fit within a regular web publishing system, and make for really ugly urls [not critical, but -2 style points:]), and as far as I can tell impossible to communicate with (I still haven't tried calling js in 'opener' with UniversalConnect granted, but don't think that would work anyway).

I can't think of any security risk to allowing a web page to call autoRegister, so let's open that function up. Are we using XPInstall in this case? Seems like XPInstall should be able to do this.

Reassigning this bug to Mitchell Stoltz following the 2PM meeting between Angelo Nunes, Mitchell Stoltz, Jesse Ruderman, Sean Su, and myself. mstoltz, if the component is incorrect, please retarget. This bug needs a pdt+ on it.

This doesn't need to be in the 7/2 candidate build, but it should be in the next one. We've decided to make Components.manager.autoRegister() all-access so it can be called from a web page.

Setting default QA -

Taking from Mitch.

Mitch, RTM stopper type of bug?

This is an important bug for the folks from EA, Lisa, and will help them to get their stuff working on Mozilla browsers.

Jesse, per our discussion adding an additional method to nsIComponentManager/nsComponentManagerImpl that takes no parameters and forwards to the existing AutoRegister method seems like a good solution. I checked the code and the component registry appears thread safe, so there shouldn't be any issues there. I timed the call under debug, and it takes close to a second to complete when it registers a single component. I suspect some increase in release, but I suspect much of the time is IO so the increase will probably be slight. Some interesting facts, the "when" parameter is only tested for the shutdown case, I couldn't find any code that tested it for anything else. The inDirSpec parameter is null in all but one call I could find that called it and then it passed it a string of all things and not a pointer to nsIFile, it was in a URL test case or something.

*** Bug 74517 has been marked as a duplicate of this bug. ***

r=dbradley Looks pretty clean, but make sure you get someone with more experience with XPCOM for another r or the sr.

Quick question, does this mean i can use an xpi that i just installed, without a restart? Does this include reloading chrome that I added during that install?

+nsComponentManagerImpl::CanCreateWrapper(const nsIID * iid, char **_retval) +{ + printf("yid\n"); That's gotta go. + // Allow scripts to call Components.manager.refreshComponents + static const NS_NAMED_LITERAL_STRING(s_refreshComponents, "refreshComponent + + const nsDependentString name(methodName); + + if(name.Equals(s_refreshComponents)) 1) The comment is misleading: scripts can call all sorts of methods on Components.manager. I think you want to sprinkle in the word "unprivileged" somewhere. 2) You shouldn't need to create the |name| wrapper in order to make the comparison: just use nsCRT::strcmp to compare |methodName| with |s_refreshComponents.get()|. Can you explain to me why we're not just exposing Components.manager.autoRegister, perhaps with some call-context checks to see make sure we ignore the parameters if we're called from unprivileged script? I think I'd prefer that to adding another method, but I can live with this mechanism if the reasons are good.

Regarding Shaver's last comment about exposing autoRegister. autoRegister took a path, and so it was thought this might pose a security risk, if a script could specify any path for this call. Is that assumption false?

>Can you explain to me why we're not just exposing >Components.manager.autoRegister, perhaps with some call-context checks to see >make sure we ignore the parameters if we're called from unprivileged script? I >think I'd prefer that to adding another method, but I can live with this >mechanism if the reasons are good. We could expose autoRegister and make autoRegister ask the security manager whether there's untrusted code on the JS stack, but I don't think the security manager is necessarily loaded at the point when autoRegister is called. I could make autoRegister say "if I can't find the security manager, assume we're just starting up and allow the parameters", but I'm worried that a malicious web page might be able to cause finding the security manager to fail by eating up all of my computer's memory.

This is in response to Jason Kersey's quick question: Jason, if your xpi dropped an XPCOM component into the components directory, then using JavaScript which is in scope in a web page, yes, you can refresh your component without restarting. However, I think bug 88443 will be of interest to you given your mention of xpi.

This goes to Arun: how would an example of JavaScript code inside an install.js XPI installer script look like? Is autoRegister(...) visible to the XPI API after the last fix?

Quick response to Tobias and those interested in this bug: No, this bug doesn't put this method into scope into XPI, ONLY from a (most likely network delivered) web page. bug 88443 is a "request to work" so that XPI can have a similar refresh method. If you would like to make syntactic/signature suggestions for what such a method will look like, drop your suggestions into that bug.

PDT gave me permission to pdt+ this one after the plugins meeting on Friday. Jesse, whenever the branch opens, let's get this one in.

When the fix of this bug isn't a solution to the bug I filed in <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=74517">bug 74517</a> why mark 74517 a duplicate of this one here?

It is a solution, albeit not the best one. You'll be able to auto-refresh components after an XPInstall from a script on a webpage. This is a temporary fix. Later, we're going to add this functionality to XPInstall's JS context, so you can run autoregister from the install.js script. Would that more directly address bug 74517?

I would still prefer adding a security check to the existing function when it is called with parameters, rather than creating a new function...did we ever test that to see if it works? However, in the interest of time and because of the possible startup-order problems that could be caused by the alternate solution, r=mstoltz on the existing patch.

Mitch and jst and convinced me to try to come up with a patch that doesn't change the interface. I'll work on that and hopefully I'll post a patch tomorrow.

r=mstoltz on the patch v4.

I'd suggest initializing maySpeciftParams to PR_FALSE and not setting in the else case in nsComponentManagerImpl::AutoRegisterImpl(), i.e.: + PRBool maySpecifyParams = PR_FALSE; ... + if (NS_SUCCEEDED(rv)) + { + rv = securityManager->IsCapabilityEnabled + ("InstallComponents", &maySpecifyParams); + if (NS_FAILED(rv)) return rv; + } + else + { + NS_ASSERTION(0, "autoRegisterImpl can't get nsScriptSecurityManager"); + } + ... Other than that the changes look good to me, sr=jst

r=mstoltz on v5.

The line below causes me some concern. if ((when != NS_Script && when != NS_Startup) || inDirSpec) This is one of the reasons I opted for a separate method. Potentially NS_Timer and NS_Shutdown cases will be security checked, when they weren't before, which might result in failure of that code. Honestly I couldn't find any cases where AutoRegister was called with either NS_Shutdown or NS_Timer so it's probably not a big deal. To me it seems AutoRegister's intent was more of an internal function. And by having these new paths security checked that weren't before, we'll shoot someone in the foot down the road. Thinking specifically of the NS_Shutdown case.

Why is that a problem? If the function is called internally, the security check will always succeed, right?

I wasn't sure if whenever AutoRegister was called, at Startup or potentially shutdown, the security manager would be available and the code treats the absence of a security manager as a failure. Mitch if your saying that the security manager should always be accessible during these calls, then I think the patch is fine and consider this r=dbradley. I just didn't know enough to make that assumption.

Checked in on trunk and branch.

This check-in broke the Mac installer (bug 90197). I'm working on a fix. I'll probably fix it by making autoRegister allow registration by default if it can't find the security manager. Alternatives include: (1) changing the nsIComponentManager interface to add a refreshComponents function instead of doing the security check in autoRegister, and (2) having autoRegister somehow know that it was called by installer and skip the security check in that case.

To fix the install bustage this caused (see bug 90197) jesse, mitch and I decided to back out the v5 patch and use v2 instead. Adding a brand-new simple method was preferable to adding another argument that would require changes in many, many places.

You mean you broke binary compatibility of nsIComponentManager? I hope you're going to shout that from the rooftops.

FWIW, I think the installer should put its own (highly permissive) security manager in place to solve this issue, rather than changing nsIComponentManager. If we decide not to do that, for whatever reason, then I think we should put the refreshComponents on another interface, which the Components.manager object can implement and get flattened into place. Reopening for more discussion. Another question: were either of v2 _or_ v5 super-reviewed?

(_Really_ reopening.)

Andrei and I were discussing why navigator.plugins.refresh() doesn't do this? Is there any reason why we wouldn't want to do it there? Here's Andrei's patch: Index: nsPluginHostImpl.cpp =================================================================== RCS file: /cvsroot/mozilla/modules/plugin/nglsrc/nsPluginHostImpl.cpp,v retrieving revision 1.275 diff -u -r1.275 nsPluginHostImpl.cpp --- nsPluginHostImpl.cpp 2001/07/02 20:08:17 1.275 +++ nsPluginHostImpl.cpp 2001/07/09 22:00:55 @@ -2321,8 +2321,14 @@ // set flags mPluginsLoaded = PR_FALSE; + //refresh the component registry first, don't care about rv? + nsresult rv; + nsCOMPtr<nsIComponentManager> compManager = do_GetService(kComponentManagerCID, &rv); + if (compManager) + compManager->AutoRegister(nsIComponentManager::NS_Startup, NULL); + // load them again - nsresult rv = LoadPlugins(); + rv = LoadPlugins(); return rv; }

The navigator.plugins.refresh() approach would be ideal for us (EA.com). It would mean the Netscape version (as far as plugins go) could be pretty much opaque to our pages. When we talked about this approach earlier people were concerned about different subsystems (presumably old and new plugins) interactions and complexity. Peter's patch seems pretty straight forward to my untrained eye, thoughts?.

Sorry, Andrei's patch.

r=mstoltz on Andrei's patch if we want to do that instead. Shaver raises some good points.

if you do an lxr search for status FROZEN or status UNDER_REVIEW, you'll see that nsIComponentManager isn't one of the chosen interfaces. However, we probably still shouldn't break binary compatibility. Shaver, can you sr= Andrei's patch? peterl or av, can you back out jesse's changes in favor of av's patch if Shaver gives his sr=? av's patch calls AutoRegister just as jesse's did, and appears pretty benign. Can compManager ever be null (can do_GetService ever fail)?

Who sr'd the checked-in-for-non-blocker-bug patch, anyway? I think shaver has a point about a separate get-able interface rather than adding a method to nsIComponentManager, and also/prior-to-that-being-needed about using a permissive security manager for the installer only. Someone care to argue otherwise? /be

There are no security checks for installer scripts: once you can run arbitrary binary bits on the disk you can get around any block we could put up. Andrei's patch has the nice side benefit that Install.refreshPlugins() will magically start registering components as well, taking care of bug 88443. The non-reviewed check-in was to fix blocker bug 90197 which was caused by the original "v5" fix in this bug. I suppose a simple back-out of v5 and reopening this one for more review would have been a better choice in hindsight.

brendan, the bug for a "permissive" installer solution is bug 88443 -- wow! dveditz's news comes as a wonderful surprise, that this patch somehow kills two birds with one stone. :-) this (perhaps erroneous) check in is in place because it's requested by an important partner, and we "backbenched" the related xpi bug (bug 88443) because not all embedders use xpi, and thus, there had to be a javascript mechanism of some sort to refresh components in a upcoming Moz' release. we can back out jesse's change and restore nsIComponentManager's binary compatibility if there's no consequences in av's patch (which peterl cut and pasted here on 07-11).

It sounds like the right people for this bug are still discussing possibilities. I'd like to reiterate that Andrei's patch above looks fine to me as an alternative to Jesse's v2 patch which is on the tree right now. At this pont, this bug should probably be reassigned to someone with a better understanding of what's going on. Reassigning to Peter Lubczynski. Peter, could you back out Jesse's v2 and check in av's patch instead, if that's the right thing to do?

Mitch, FWIW I agree. This handles my original concern of potentially affect current or future code by changing the implementation of AutoRegister and keeps the interface of the component manager intact. Adding an additional interface would also satisfy this as Shaver suggested.

dbradley, av's patch doesn't add a new interface. do you think it solves the problem? can you r= too?

Okay, back in my court. I was wondering if I could get a super review for Andrei patch from one of the super reviewers cc:ed on this bug? Also, what about "unregistering" plugins that have been removed? I know uninstall goes way beyond the scope of this bug, but I see a few "unregister" methods in nsIComponentManager.

Yes, Andrei's doesn't create a separate interface, but appears to solve the immediate problem. I don't have enough knowledge to say which is better. Andrei's seems less of an impact at this point and fairly simple. Minor nit about Andrei's patch replace NULL with nsnull or 0. It wouldn't be alone if you left it, though. r=dbradley

Hi. Mitch, can you please tell me how both v5 got into the tree (on the trunk -- I don't think we care about the branch) without super-review being indicated in the bug? Thanks. I really appreciate it.

In order to restore binary compatibility of nsIComponentManager (which is not inviolate, but whose alteration certainly requires more care and consideration than was taken in this case), and in response to the abuse of process that led to v5 being checked in in the first place, I've decided to back out the current (v2) patch from the trunk. I'll be doing that this afternoon (PDT). I highly recommend that Netscape back it out of their branch, as well, to preserve binary compatibility with past and future Mozilla releases. We will _not_ necessarily take pains to be compatible with this interface change, even if it should stand in a Netscape release.

Okay, I'll back it out. Shaver, can I get your sr= blessing on the patch to nsPluginHostImpl in my July 11th comments?

If you don't care about rv, don't define it early just to pass it to do_GetService and ignore the value. For that matter, since you're linked with libxpcom anyway, you should be able to just use the nsComponentManager::AutoRegister symbol directly. I'm not sure that we shouldn't return an error code if either of the component or plugin refreshes fail, though. As an installer-JS author, I think I'd want to get an exception so that I can inform the user that something has gone wrong, etc. What say you to: nsresult rv = nsComponentManager::AutoRegister(...); nsresult rv2 = plugins->refresh(); if (NS_FAILED(rv)) return rv; if (NS_FAILED(rv2)) return rv2; return NS_OK; or something of that ilk? Arun, Jeff, what do you think we should tell the script author if the registration fails? (If navigator.plugins.refresh() was infalliable in 4.x or before, then we have a harder decision to make.)

I think knowing that the registration failed would be good info (especially for late night debug sessions). Doubtlessy the return value will almost always be ignored, but if anyone is checking for it... it'd be nice if it was truthfull. But, as you said, if 4.x didn't return the actual success, always 'true', or didn't return anything, then adding this would break a bunch of legacy code. How does js handle this? function func() { //do stuff, but don't return anything } function badfunc() { if(func()) { //do somehting else } } I assume it pops an error.

Jeff Price: no, JS returns undefined if you fall of the end of a function, and undefined is a first-class type with one value, which converts to false in an if condition. http://lxr.mozilla.org/classic/source/lib/libmocha/lm_plgin.c#875 shows that 4.x plugins.refresh() returns undefined by default -- it does not set *rval. So if we want to be strictly compatible, we would have to signal failure by a different return value. But I think shaver was proposing that we let XPConnect throw a genuine JS exception, which would preserve the void return type. Throwing an exception for a novel, exceptional case seems ok to me -- the case and the throw are compatible with each other, and new. /be

The original v5 patch had a super-reviewer indicated in the check-in comments. Yeah, it was wrong not to be noted here, but if you're going to go on an "abuse of process" jihad don't just pick on Mitch--it's very common. (Admittedly subsequently checking in v2 was wrong in hindsight, we should have just backed out v5 to fix blocker bug 90197. But when managers and sheriffs are breathing down your neck about why the blocker isn't fixed you don't always think straight.) In the past navigator.plugins.refresh() never threw exceptions. I'd worry if it started doing so now. As much as it'd be nice to have bug 88443 go away without me doing anything I'm worried about unintended side-effects if refreshing plugins starts registering components. They are different things; a separate API is cleaner and safer. Especially true since this change isn't going to get a lot of real-world testing this close Netscape shipping.

refresh.plugins() should refresh components if we agree that semantics of 'plugins' includes xpcom plugins too. Why are you worried with registering components? This is something which is performed every time on start up. Can you give some hypothetical scenario when this could actually hurt, so I have clearer understanding?

dveditz: I didn't look for the checkin comment (mea culpa, I guess), but it's certainly not a case of picking on Mitch. I call them when I see them, which is, perhaps unfortunately, an exercise bounded by my ability to monitor bugs and checkins. Ask jud, though -- I've been on this "jihad" for a while. (Death to infidels!) av: we had better not be autoregistering components on every startup, in release builds. We did at one point recently, but it was an error (and a painful one), and I believe cathleen and waterson fixed 'er up.

Wait. I don't understand it then. How are we supposed to pick up new components? Besides, that patch I suggested is just a replica of what we do on start up. Or you are saying it's ifdef'd to be debug only?

To avoid a potential confusion. To my understanding nsComponentManager::AutoRegister() checks if a component changed compared to what we already have in the registry and registers it only if it changed. It does not re-register all components in the comp folder. Is this correct?

Andrei's patch, Andrei's bug? ;) If not, send back to me.

The above patch (v6) is so called 'Andrei's patch' with corrections along shaver's comments. If people think this is a way to go, can I get an sr= to check it into I beleive both the branch and the trunk?

The startup autoreg is conditional in optimized builds (one of the conditions being "did someone use XPInstall in the last session", the main one being "did component.reg go away"). The performance cost even of file timestamp checking every time is pretty bad on some systems as we found in PR1. Users can also use the regxpcom utility (not shipped on Mac, apparently).

We cann't use regxpcom.exe because, just like XPInstall, not all embedding Gecko's that support plugins ship with an external tool to do registration. I still think that plugins.refresh() should be complete in plugin registration. I think not always doing autoReg() at startup is even more reason to do it with plugins.refresh(). But, if you are worried about problems this late in the game, what if this only refreshed components whole's filenames began with "np"?

Peter, are you saying you are proposing to introduce some limitations on xpcom plugin file names? I don't know... OK, I have a clearer picture on what happens on start up, this makes sense. But I still don't see how updating the component registry can hurt us during plugins.refresh(). As Peter said, we can even look at it at another angle -- as an advantage.

I'm not saying we shouldn't have a command to refresh components (and I certainly don't support something with name limitations), I'm suggesting that a new API to keep the functionality separate would be safer in the face of unforeseen future problems. But that's just a vague feeling of foreboding, and obviously others object just as strongly to the idea of a new API in a non-frozen interface. Feel free to check this solution in, I can't find any actual problems with it.

Is that an sr= then Dan? Can this get checked in today? We're out of time...

me Dan? I'm not on the sr= list. but r=dveditz if you need it. (I can sr= for the Netscape branch, but not the trunk. Since we don't want to do two different things I think you should get a mozilla sr=).

shaver, any qualms for sr= ? i'm not certain if the last issue you raised about autoregistering upon startup was successfully resolved. we'd love your sr for trunk (and branch) since we're in a sort of time crunch!

Andrei, either way if you don't get an sr= for this patch, can you back out mstoltz's changes from the branch today? The best thing would be to get an sr= for your patch and check that in as well. I was working with Syd on bug 89488 on Linux and I have a wild guess that this bug may be causing it since it's fixed on the trunk but not the branch and it went in around the same time that bug started happening.

bug 89488 was written up on 7/5, before anything was checked in to fix this bug. The check-ins for this bug happened roughly the same day the trunk got better, but AFAIK the same thing was checked in to both trunk and branch.

Is my understanding correct that v2 has already been backed out of the trunk and I need only remove it from the branch? Do I need a special permission for doing that?

Actually, I just looked at CVS log and it doesn't look like Shaver actually backed out anything on the trunk. At least the CVS log for nsComponentManager.cpp doesn't show anything. Now I don't think this related anymore, sorry.

OK, from my understanding, we are going to back-out the component manager changes (v2 and/or v5?) and instead just make the call to register any new components (V6 patch) whenever the plugins.refresh method is called (Peter L. told me all of this). SR=attinas on that plan and patchID 42255.

OK, I also got an sr=shaver in email for backing out v2 changes and getting my patch in.

Diffs from id=41493 (v2 patch) reversed in the branch. Patch v6 checked in on the branch.

All the same is now applied to the trunk too. Closing.

Okay, after talking to Arun, and building the testcase at http://voodoolady/security/bugs/bugzilla87913.html , I've determined that this bug is VERIFIED FIXED for: 2001-07-19-05-0.9.2 Win98SE AND... it still needs verification on Macintosh & Linux platforms, as well as on the trunk for all platforms.

Okay, this has been verified on 2001-07-19-xx-0.9.2 bits for both Macintosh & Linux... Checking 2001-07-20-0x-trunk bits on all platforms next...

Marking VERIFIED FIXED: MacOS91 2001-07-20-08-trunk Win98SE 2001-07-20-05-trunk LinRH62 2001-07-20-08-trunk NOTE: The testing on Mac & Linux was done by moving the Shockwave Plugin completely out of the 6.x directory, running the testcase above, then putting the Shockwave Plugin back into the proper plugins directory and re-running the testcase. Plugin shows up when navigator.plugins.refresh is run and navigator.plugins list is generated. If anyone disagrees with this method, please alert me. Otherwise, I'm considering this bug VERIFIED FIXED.

I think to be really sure you need to delete components.reg... The component does not get unregistered just by removing it. 1) remove the plugin 2) delete components.reg 3) start the browser (no testing, this is to rebuild the components.reg file) 4) kill the browser 5) start the browser 6) run test to make sure the plugins is not available 7) copy the component back into the components directory 8) call navigator.plugins.refresh(true); 9) re-test for availability. at least this is how i test on win32 machines...

Testing this with legacy plugin like Shockwave is not right thing to do. The fix in this bug was about adding refresh to xpcom components, refreshing legacy plugins was already there. I am not sure what xpcom plugin are available on Linux and Mac, Real is one on Windows. But you can use npsimple plugin which is a sample code and is as far as I know a part of the debug build. Xpcom plugin consists of two files: one is dll (or analog), the other is .xpt file. So, 'remove plugin', 'copy plugin' should be taken as doing this with two files not just one. With this in mind steps in jprice's comment should do the trick. Also note: components folder, not plugins folder.

Okay, re-verifying...

Okay, so I've verified this (trunk & branch) using the npcdt.dll & npcdt.xpt as I've mentioned in previous comments - av, please let me know if the use of the npcdt.dll & .xpt files is appropriate to what you stated earlier. Arun wrote this bug up specific to windows, so okay, verified fixed on windows. As far Mac & Linux go, there appear to be no similar types of xpcom plugins which will show up when navigator.plugins is polled, so the testcase @ http://voodoolady.mcom.com/security/bugs/bugzilla87913.html can't check for them. My point: I would prefer to verify this on Mac & Linux (since it's xp functionality) but I don't yet have a clear idea of how to do so on Mac & Linux. I am hoping to talk to dveditz to gain some of that clarity :-). av: since I'm not setup to build debug, would you mind emailing me the two npsimple.* files you mentioned for Mac & Linux? Thanks.

Realplayer is an XPCOM plugin on Mac, maybe on Linux too. Put it and the xpt file in your components directory and try to listen to Netscape Radio ;)

>av, please let me know if the use of the >npcdt.dll & .xpt files is appropriate to what you stated earlier. That's exactly what needs to have been done. Unfortunately, I don't have current Linux and Mac builds. Peter says you can try Real for Mac. This should be enough.

Great suggestions guys, thanks! I have another thought after talking to mstoltz & dveditz: After doing: 1) remove the [xpcom] plugin 2) delete components.reg 3) start the browser (no testing, this is to rebuild the components.reg file) 4) kill the browser 5) start the browser 6) run test to make sure the plugins is not available 7) copy the component back into the components directory 8) call navigator.plugins.refresh(true); 9) re-test for availability. I'll do item #8 in one window, and have a testcase that makes a privileged call to Components.* to poll for the [non]/existence of the xpcom components (the test would also be run @ step#6). I'll post results in a bit...