bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Need a Dialog Free Mechanism to Refresh New Component

VERIFIED FIXED in mozilla0.9.3



17 years ago
17 years ago


(Reporter: Arun Ranganathan, Assigned: av (gone))




Firefox Tracking Flags

(Not tracked)




(6 attachments)



17 years ago
* 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()
		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
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!


17 years ago
Keywords: mozilla0.9.2
Priority: -- → P1

Comment 1

17 years ago
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!

Comment 2

17 years ago
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.

Comment 3

17 years ago
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.

Comment 5

17 years ago
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.
Assignee: ssu → mstoltz
Component: Installer: XPI Packages → Javascript Engine


17 years ago
QA Contact: gbush → pschwartau
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.

Component: Javascript Engine → Security: General
Keywords: nsBranch

Comment 7

17 years ago
Setting default QA -
QA Contact: pschwartau → ckritzer

Comment 8

17 years ago
Taking from Mitch.
Assignee: mstoltz → jesse
Target Milestone: --- → mozilla0.9.3

Comment 9

17 years ago
Mitch, RTM stopper type of bug?

Comment 10

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

Comment 11

17 years ago
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.

Comment 12

17 years ago
Created attachment 41155 [details] [diff] [review]
fix: create Components.manager.refreshComponents() and make it callable from scripts

Comment 13

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

Comment 14

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

Comment 15

17 years ago
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"

2) You shouldn't need to create the |name| wrapper in order to make the
comparison: just use nsCRT::strcmp to compare |methodName| with

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.

Comment 17

17 years ago
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?

Comment 18

17 years ago
>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.

Comment 19

17 years ago
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.

Comment 21

17 years ago
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?

Comment 22

17 years ago
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.

Comment 23

17 years ago
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.
Whiteboard: pdt+

Comment 24

17 years ago
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?


17 years ago
Whiteboard: pdt+ → pdt+ have r, need sr
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.

Comment 27

17 years ago
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 


17 years ago
Whiteboard: pdt+ have r, need sr → pdt+ working on a new patch, eta evening of tue 7/10

Comment 28

17 years ago
Created attachment 41873 [details] [diff] [review]
fix v3: this patch doesn't make any changes to interfaces


17 years ago
Whiteboard: pdt+ working on a new patch, eta evening of tue 7/10 → pdt+ need r and sr for new patch

Comment 29

17 years ago
Created attachment 41883 [details] [diff] [review]
fix v4: if we can't get the security manager, assume caller isn't privileged
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

Comment 32

17 years ago
Created attachment 41890 [details] [diff] [review]
fix v5: initialize maySpecifyParams to false
r=mstoltz on v5.

Comment 34

17 years ago
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?

Comment 36

17 years ago
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.
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 38

17 years ago
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.)
Resolution: FIXED → ---

Comment 43

17 years ago
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;

Comment 44

17 years ago
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?.

Comment 45

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

Comment 47

17 years ago
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?

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.

Comment 50

17 years ago
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? 
Assignee: jesse → peterlubczynski

Comment 52

17 years ago
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.

Comment 53

17 years ago
av's patch doesn't add a new interface.  do you think it solves the problem? 
can you r= too?
Whiteboard: pdt+ need r and sr for new patch → pdt+ , need sr for av's new patch

Comment 54

17 years ago
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.
Whiteboard: pdt+ , need sr for av's new patch → [PDT+][SEEKING SUPER REVIEW]

Comment 55

17 years ago
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.

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.

Comment 58

17 years ago
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,
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.)

Comment 60

17 years ago
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()
      //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

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.

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.

Comment 63

17 years ago
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 
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

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.

Comment 65

17 years ago
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?

Comment 66

17 years ago
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?

Comment 67

17 years ago
Andrei's patch, Andrei's bug? ;)

If not, send back to me.
Assignee: peterlubczynski → av

Comment 68

17 years ago
Created attachment 42255 [details] [diff] [review]
fix v6 -- extending already existing plugin.refresh with components

Comment 69

17 years ago
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).

Comment 71

17 years ago
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"?

Comment 72

17 years ago
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.

Comment 74

17 years ago
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=).

Comment 76

17 years ago
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!

Comment 77

17 years ago
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.

Comment 79

17 years ago
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 

Comment 80

17 years ago
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.

Comment 81

17 years ago
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.

Comment 82

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

Comment 83

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

Comment 84

17 years ago
All the same is now applied to the trunk too. Closing.
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 85

17 years ago
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


it still needs verification on Macintosh & Linux platforms, as well as on the 
trunk for all platforms.

Comment 86

17 years ago
Okay, this has been verified on 2001-07-19-xx-0.9.2 bits for both Macintosh & 

Checking 2001-07-20-0x-trunk bits on all platforms next...

Comment 87

17 years ago

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.

Comment 88

17 years ago
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...

Comment 89

17 years ago
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.

Comment 90

17 years ago
Okay, re-verifying...

Comment 91

17 years ago
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.

Comment 92

17 years ago
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 ;)

Comment 93

17 years ago
>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.

Comment 94

17 years ago
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...


17 years ago
Keywords: topembed
You need to log in before you can comment on or make changes to this bug.