Closed Bug 85488 Opened 23 years ago Closed 21 years ago

navigator.mimeTypes array does not refresh

Categories

(Core :: DOM: Core & HTML, defect, P1)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 150087

People

(Reporter: jprice, Unassigned)

Details

From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; DigExt) BuildID: 2001052904 After a call to the code blurb below in 0.9.1, new mime types picked up in the refresh of the 'components' directory fail to show up in the navigator.mimeTypes [] array. This is a large block to dynamically installing components, as I can install a component but have no way of knowing that the install succeeded. Which means I'll probably have to ask the user to restart the browser everytime we install a component (which could be several times a session). ... netscape.security.PrivilegeManager.enablePrivilege('UniversalXPConnect'); Components.manager.autoRegister(0, null); ... Reproducible: Always Steps to Reproduce: 1. load a page that dumps all mimeTypes: <html><body><script> function doRefresh() { try{ netscape.security.PrivilegeManager.enablePrivilege ('UniversalXPConnect'); Components.manager.autoRegister(0, null); }catch(e){alert("An unexpected error was encountered (" + e + ").");} } for i=0;i<navigator.mimeTypes.length;i++) document.write(navigator.mimeTypes[i].type + "<br>"); </script><a href="javascript:doRefresh();">Refresh Components</a></body></hmtl> 2. drop a previously unregistered component into the components directory. [If you have to use a component already in the components dir, removed it from the dir, delete components.reg (in the 'Netscape 6' dir), start the browser (to recreate a components.reg) , kill it (it's not in a very healthy state as far a components go), then start it again.] 3. Refresh the page, note the new plugins MIME type is not listed. However if you try to instantiate it directly with XPConnect it will succeed. Also the registry is listed in components.reg. Actual Results: The MIME type array showed no changes Expected Results: The MIME type array (navigator.mimeTypes[]) would reflect the new components.
This is not an xpconnect problem. Reassigning to DOM0 - Perhaps people who know DOM bugs might identify this as a dup or decide this is a plugin issue.
Assignee: dbradley → jst
Component: XPConnect → DOM Level 0
QA Contact: pschwartau → desale
Isn't this just an issue with the fact that only plugins show up in navigator.mimeTypes?
My understanding is that component mime types show up in the mimeTypes array as well. And the mime type for components found at startup are currently included in the mimeTypes array. So either way it is at least inconsistant.
Status: UNCONFIRMED → NEW
Ever confirmed: true
jprice is right: components DO show up in the mime types array -- take a look at the beatnik plugin for a 'famous' example. if you do an "about:plugins" in the URL, you'll see that beatnik is installed in the components directory, but displays in the mime types directory. so refreshing the mime types directory based on the latest component installed is clearly important. CC'ing Sean from Beatnik, and the plugin engineers, and raising priority. This blocks EA from doing Mozilla work, and EA make great games, so this blocks Mozilla users from playing great XPCOM based games :-(
Priority: -- → P1
Also note to my previous comments: the component may be refreshed by using Components.manager.autoRegister(0, null); but is there a way for the programmer to detect this refresh? Any workaround suggestions would go over well :-)
Though the Beatnik plugin is an xpcom component, the reason that it and its mimetypes appears in about:plugins is because it explicitly calls nsIPluginManager::RegisterPlugin (http://lxr.mozilla.org/seamonkey/source/modules/plugin/nglsrc/nsPluginHostImpl. cpp#2370) during auto-registration. There's nothing in the component manager to handle component mimetype registration. About:plugins displays only plugin mimetypes - no helper apps, or non-plugin xpcom components.
Our XPCOM components call nsIPluginManager::RegisterPlugin() as well. And they do show up in the mimeTypes[] array after the browser is restarted. The problem is when we download/install the component and call the equivilent of Components.manager.autoRegister(0, null) the new component does NOT show up in the mimeTypes[] array. So although through our installation process we know the component was installed and assume the component was auto-registered, we do not have (or know of) a mechanism to verify this through JS.
I see. I don't know how navigator.mimetypes is populated. Have you tried using navigator.plugins rather than navigator.mimetypes? Try a navigator.plugins.refresh(false) before iterating through the plugins. You can get the plugin mimetypes via navigator.plugins[x].type.
Question: will Components.manager.autoRegister(0, null) even work from a network delivered page?
The plugin refresh code only refreshes legacy plugins and XPCOM plugins. For XPCOM it means that it looks under "software/plugins" key in the component registry. I think the place where navigator.mimetypes is populated is MimeTypeArrayImpl::GetMimeTypes in mozilla/dom/src/base/nsMimeTypeArray.cpp The code there shows that we only look in plugins for this javascript command.
Components.manager.autoRegister(0, null) does not work from a network delivered page unless it is in a signed jar and the user grants permission, which is one way we have tried doing it. The other way is a call to nsComponentManager::AutoRegister(...) from within one of our previously installed XPCOM components (which currently requires a browser restart to get the mime type).
Firstly, to answer peterl's question: "Question: will Components.manager.autoRegister(0, null) even work from a network delivered page?" peterl, YES if the page is signed and using code like this: funtion func() { netscape.security.PrivilegeManager.enablePrivilege('UniversalXPConnect'); Components.manager.autoRegister(0, null); } Secondly, I'm unclear: is this supposed to work or not, e.g. when a component is installed, and it registers itself for a mimetype, is there a mechanism to make it appear in the mime types array without restarting? Also, if NOT, then how can a developer tell that the component was successfully installed via JavaScript? Thirdly, nominating mozilla0.9.2 -- by that time, we need to know whether this is possible or whether there's a workaround.
Keywords: mozilla0.9.2
Why the focus on mimetypes? If someone has a plugin and needs to know if it's been installed, iterate through navigator.plugins after registration and navigator.plugins.refresh(false). If registration was successful and the plugin isn't in the plugins array, then that needs to be resolved - probably in the plugin manager. As far as mimetypes go, is there a navigator.mimetypes.refresh() method?
Ah.....yes signing is good. Yes, why all the focus on mime types? If you are implementing, set a breakpoint in nsIPlugin::GetMIMEDescription(). Thinking about this....components are not plugins so why should registration effect the mimeTypes array? Based on current summary, I nominate INVALID. Only plugin registration should effect that array, I think, unless that's broken. Jeff, have you tried: navigator.plugins.refresh(false); or through XPCOM: nsIPluginManger.reloadPlugins That code path will "register" your nsIPlugin interface implementation with "layout" so the MIME type array should get updated, however "false" will prevent the page from reloading. I think there is still the requirement that it must begin with "np", not sure. Anderi may know more. Also, you can try to remove the [no script] on nsIPluginManager.RegisterPlugin and call it directly (not 100% sure that will work, but very easy to try). Um...this is weird, can someone try to reproduce. Use the Real Player as a simple test. Quit Mozilla/Netscape and remove/copy components/nppl3260.dll and the xpt. Notice upon each restart, about:plugins doesn't seem to update at all or is this just my build playing tricks on me. Or, perhaps this bug is VALID and about:plugins is really broken.
navigator.plugins[] is an array of plugins, not XPCOM components. The navigator.mimeTypes[] array overlaps both components and plugins. The catch/bug is the array only holds the mime type of components that were present at browser start up. When we download a new component and call the equivilent of Components.manager.autoRegister(0, null) the component succesfully auto registers (nsIPluginManager::RegisterPlugin()), however the new components mime type is not placed into navigator.mimeTypes[] until the browser is restarted. navigator.mimeTypes[] is the one of the mechanisms we use to determine if the required components is already present or whether we need to trigger our XPI script. Finally, since the objects I'm writing need to be scriptable, they need to be components so navigator.plugins doesn't apply (i think).
If you are not implementing the plugin API, I'm not sure on the relationship between navigator.mimeTypes[] array and XPCOM components. adding Mike Shaver and Chris Waterson into the disucussion. I thought an XPCOM component that had a mime type was called a plugin and therefore implemented nsIPlugin and was reloaded with plugins.refresh(), but I may be wrong. I think there are better ways of checking for correct installation. Have you tried doing a QI? Looking at nsIPluginManager::RegisterPlugin, looks like it just writes some keys to the moz registry. No wonder it fails. Try looking at the code path of ReloadPlugins()-->LoadPlugins()-->LoadXPCOMPlugins()~~~~~> nsPluginHostImpl::RegisterPluginMimeTypesWithLayout(). You may need some of that logic but it looks to be specific to nsIPlugins.
Peter, Unless I am incorrect, MIME types are not limited to plugins. Components can (and do) register as supporting MIME types and are embedded on the page based on MIME type the same way plugins are. At best NS6.x is inconsistant. The MIME types of registered components DO show up in the navigator.mimeTypes[] array if they were present at browser startup. Since the new component architecture is the replacement for scriptable plugins, we need mechanisms to determine what is present and available like the mimeTypes array. Every other detection scheme I have found involves direct XPConnect calls, which not only requires a myriad of security pop-up due to NS's limited scope of granted permissions, also require the script and every associated file to be seperated from the rest of our site in signed jar's which are clamped down incredibly tight. While this makes for a nice and secure environment, it also makes any user experience less than acceptable... but that's another issue altogether. Perhaps there is another way to achieve our ends. Here's the flow I need to achieve: user comes to our site does not have an up to date installer component (EAMozSnpy) as detected by InstallTrigger.CompareVersion (bug 85564) and navigator.mimeTypes[]) we download and invoke a Wise installer wait for installation to complete or be cancelled the installation is cancelled close the current page and are done user now has an up to date version of EAMozSnpy We use EAMozSnpy to download a game or other piece of software the user has requested (we'll assume it contains a Moz XPCOM component) wait for installation to complete or be cancelled We confirm the install was complete by NS acknowleding the mime type as ready to be embedded the mimetype is not available display an error and call it quits ------------ currently in NS6 this flows as: user comes to our site the user does not have an up to date installer component (EAMozSnpy) as detected by InstallTrigger.CompareVersion (bug 85564) and navigator.mimeTypes[]) we download and invoke a Wise installer we pop up a message to the user telling them that if they complete the installation they need to restart the browser because we have no means of knowing when the Wise installer exe invoked by XPI has completed. This restart could be avoided if we could refresh the components w/o out the security hassle AND the navigator.mimeTypes array showed any changes. the user completes the install and restarts the browser our mime type now shows up in navigator.mimeTypes[] and is embedded in a page. EAMozSnpy is used to install another XPCOM component nsComponentManager::AutoRegister(...) is called after the new component is copied to the components directory the component is succesfully auto registered we assume the component is available to embed, but can't verify this since we can't detect it in navigator.mimeTypes[]. If anything went wrong the user would be given the popup incorrectly telling them they can get the required plugin from the plugin depot at netscape. -------- on another topic I think that deleting a component does not remove it from navigator.mimeTypes[]. But I'll file another bug against this when I get some more research done into it...
1. xpcom components that implement nsIPluginInstance ARE plugins. XPCOM plugins are listed with their mimetypes in the navigator.plugins array. 2. Not all xpcom components use mimetypes. In fact, MOST DON'T. There is no such thing as automatic component registration of mimetypes. 3. Most use of javascript and the DOM involves XPConnect. 4. "deleting a component does not remove it from navigator.mimeTypes[]" - that's because you need to unregister the plugin (nsIPluginManager::UnregisterPlugin). 5. nsIPluginManager::RegisterPlugin is used to store the mimetypes that an xpcom plugin supports (along with description and file extensions).
my components implement: nsIPluginInstance, and nsIScriptablePlugin in addition to their respective scripable interfaces. If by plugins API you mean the 4.x flat set of 'c' calls, then no the component does not support that interface for NS6 (although it does for NS4.x where LiveConnect is used for the scripting). I believe my component does NOT implement nsIPlugin, since this appears to be an interface for supporting legacy plugins. I'm not sure of the NS nomenclature for these different pieces. I've been using plugin for pieces installed in the plugins directory and supporting the flat 'c' interface. I've been calling XPCOM objects installed in the components directory components. nsIPluginManager::RegisterPlugin() is the only mechanism I've seen for registering a component that will then be embedded in a page. Since the documentation is relatively light and fairly inaccurate I came to use this method of registration by digging into the Mozilla source. If there is a better way to register a XPCOM component and have it embeddable on a page without signed jars and what not, please let me know.
1. Plugin API in regard to mozilla means the nsIPluginInstance, nsIPlugin, etc interfaces. 4x plugin API is the old flat C API. 2. XPCOM components stored in the components directory that implement nsIPluginInstance are plugins (best called XPCOM plugins). 3. nsIPlugin is not for legacy support - it's part of the new API, though not required for an xpcom plugin to function (the npSimple plugin for example does not have an nsIPlugin impl).
>Um...this is weird, can someone try to reproduce. Use the Real Player as a >simple test. Quit Mozilla/Netscape and remove/copy components/nppl3260.dll and >the xpt. Notice upon each restart, about:plugins doesn't seem to update at all >or is this just my build playing tricks on me. Peter: You mean that the plugin is still listed in about:plugins? That's because you need to either have the plugin call nsIPluginManager::UnregisterPlugin before you remove the dll or you need to delete components.reg. When an xpcom plugin registers, the plugin information is written to the component registry in non-volatile manner.
Ok, I just learned a lot about the navigator.plugins array. I think i can now detect whether a component has been installed by iterating the navigator.plugin array looking for supported mime types after a call to nsComponentManager::AutoRegister(...). I won't be sure until i dig in tommorrow. This will produce some ugly code, but i'm ok with that as long as it works consitantly in rev's of NS6. I would still like a way to call nsComponentManager::AutoRegister(...) from within a non secure page so i wouldn't need the user to restart the browser, but that is another issue. I think i can now find a way through this... But I still believe this is a bug. Either these mimeTypes should not be in the mimeTypes array ever, or there should be a way to dynamically refresh that array (mimeTypes can be dynamically added). But I am happy that there is a way to find the plugin and just wish it hadn't take 2 months with a lot of support from the Moz/NS folks to find this out. While I'm on a rant: 1) If they are 'plugins' why aren't they in the 'plugins' directory? 2) If they aren't 'components' why are they installed in the components directory? 3) Why can i easily refresh the 'plugins' in the plugins folder, but need to jump through hoops to get the 'plugins' in the components folder refreshed. 4) If they are 'plugins' that just happen to live in another directory, why does navigator.plugins.refresh() not refresh them? that's enough venting for now...
How does one call nsIPluginManager::UnregisterPlugin? Since these are components we sent out into the wild of potentally millions of users, we have to assume someone will eventually delete the dll unintentionally/by accident. How do we detect that the dll is no longer present? Do you suggest we ask our users experiencing trouble to delete components.reg and then restart the browser twice as a normal remedy (it appears to take one restart to get the required subsystems registered so our registration will succeed)?
Jeff, If you haven't already, check out the sample plugin at: http://lxr.mozilla.org/seamonkey/source/modules/plugin/test it should build and run (minus a few bugs) and provide you with a sample framework to build your plugin. Check out these links (some are dated): http://www.mozilla.org/docs/plugin.html http://www.mozilla.org/docs/codestock99/pluginpreso.zip http://www.mozilla.org/docs/codestock99/pluginintro.zip navigator.plugins.refresh() is having some problem now, but I think you should still be able to refresh. Although, I'm having a problems with it even with restarting mozilla, which is what is weird. b.t.w, look at the source for about:plugins, it also does a refresh. My hunch says it's something to do with: http://lxr.mozilla.org/seamonkey/search?string=RegisterPluginMimeTypesWithLa
>1) If they are 'plugins' why aren't they in the 'plugins' directory? the plugins directory is for 4x plugins >2) If they aren't 'components' why are they installed in the components >directory? ?? All xpcom plugins ARE components. The reverse is not true. >3) Why can i easily refresh the 'plugins' in the plugins folder, but need to >jump through hoops to get the 'plugins' in the components folder refreshed. Because all xpcom components need to be registered with the component manager. And further, all xpcom plugins need to register with the plugin manager. >How does one call nsIPluginManager::UnregisterPlugin? Since these are Your plugin should be calling UnregisterPlugin in response to an XPCOM UnregisterSelf call. This can be tested by doing: regxpcom -u /the/full/path/to/your/component.dll >components we sent out into the wild of potentally millions of users, we have >to assume someone will eventually delete the dll unintentionally/by accident. This is a problem with all xpcom components - not just xpcom plugins. There may already be a bug filed about stagnant component registration info. >How do we detect that the dll is no longer present? From javascript? No idea. >Do you suggest we ask our users experiencing trouble to delete components.reg >and then restart the browser twice as a normal remedy (it appears to take one >restart to get the required subsystems registered so our registration will >succeed)? No suggestions other than figure out how you're going to deal with customer support before you release.
Changing summary to be more descriptive from: navigator.mimeTypes array does not refresh when components are reloaded Note: we are talking about navigator.mimeTypes not the plugins one.
Summary: navigator.mimeTypes array does not refresh when components are reloaded → navigator.mimeTypes array does not refresh
Targetting for mozilla1.0
Target Milestone: --- → mozilla1.0
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Target Milestone: mozilla1.0.1 → ---
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
This got fixed as a part of bug 150087. *** This bug has been marked as a duplicate of 150087 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.