linux 2000100709 When going to a site that expects a plugin or helper application, i now get popup box about "can't find plugin download plugin". Manually adding a helper application in preferences is impossible: I get this error message when clicking OK after having added the mimetype, file extentions etc: JavaScript error: line 0: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIRDFContainer.Init]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://communicator/content/pref/overrideHandler.js :: anonymous :: line 242" data: no]

This used to work, so adding regression keyword.

Wow, this is really broken. I try and add a helper app entry, it doesn't show up in the list UI after clicking OK. RDF file looks like it got my change. Restarted, new helper app still isn't there. I try to add it again, and get a warning that the helper app already exists (but doesn't show up in the list). I was trying to add application/pdf for xpdf.

the blank display is another bug. However - I'm puzzled by the differences between the file that is created via prefs in ~/.mozilla/default/mimeTypes.rdf and the one that is created at a first startup in ~/.mozilla/default/en-US/mimeTypes.rdf They seem to follow two completely different syntaxes. And while the one mozilla creates itself when you add via prefs never show up there, the one in en-US will (if moved to ~/.mozilla/default)

shrir, could you see if this happens on the other platforms? thx! nominating for rtm... i presume this was found in the trunk? (should doublecheck branch, too.)

If this bug is about the 'plugin downloader plugin' dialog, this is a dup of bug 48483. If this bug is about 'cannot add helper app', then this is a dup of bug 50914. you choose...

this looks like a dup of 50914, marking so. *** This bug has been marked as a duplicate of 50914 ***

verified.

50914 is about prefs panel for mimetypes being blank. This bug is about a specific js error. The error is not mentioned in bug 50914.

In addition, summary of 50914 reads: "Helper application panel listing is blank, cannot add mime type when using old profile". While this bug as tested and reported is with a brand new profile.

rkaa, before you add a mime type, is the mime list in the panel blank? if it isn't, this sounds different from bug 50914. (also the fact that you're seeing this with a new profile, too...) so, i'm gonna reopen this, for now. if, after the fix for 50914 is checked in, this still occurs, then this is definitely a separate bug. if does go away, cool it's a dup --i just don't want this to be forgotten in case it isn't a dup. (call me paranoid ;).

I do_not see this on linux branch bits fot today with a new profile.

I get the exact same JS error when trying to add helper apps with SEA 2000101109

Minus until someone else can reproduce this consistently.

This can be reproduced 100% consistently. Just don't import old Netscape Communicator profile. As the situation is, a user will have to install NC4* in order to get a mimteTypes.rdf placed in the correct mozilla user directory. What's more: If i cheat, and copy the now wrongly located mimteTypes.rdf from ~/.mozilla/default/en-US and one dir up, it's visible in prefs panel, but err's when adding helper apps, and once added, they can't be edited/modified. The first error in edit appears as soon as you click a radiobutton: JavaScript error: line 2: this.selectedItem has no properties The second error is this, when clicking OK after modifying an entry: JavaScript error: line 0: uncaught exception: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIRDFDataSource.Change]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: chrome://communicator/content/pref/overrideHandler.js :: changeMIMEStuff :: line 338" data: no] Can someone please try a clean install - no migration - no import of anything old - just a brand new fresh mozilla installation, please. There are so many errors regarding helper apps, plugins and mimetypes under linux, it's hard to know where to begin filing bugs.

Unforuntately you seem to be the only one getting a mimetypes.rdf file in a en-US locale directory. This works just fine for me a clean linux install. I don't know what it is about your system that's causing that.

From install log 2000101221: [dark@localhost mozilla]$ grep mime install.log [1/18] Installing: /usr/local/mozilla/components/libmime.so [4/18] Installing: /usr/local/mozilla/components/libmimeemitter.so [6/18] Installing: /usr/local/mozilla/components/libsmime.so [6/33] Installing: /usr/local/mozilla/defaults/profile/en-US/mimeTypes.rdf This is the full installer routine performed, where XPinstall downloads from web and does everthing. After starting mozilla first time as root, mimeTypes.rdf is located in /root/.mozilla/default/en-US/mimeTypes.rdf How can this be a local error?

and panels.rdf and localstore.rdf are all created in the correct directory for you? This is the only rdf file that's created in a en-US directory?

as you see i grep'ed for "mime". This is a grep for rdf: [27/167] Create Folder: /usr/local/mozilla/res/rdf [28/167] Installing: /usr/local/mozilla/res/rdf/loading.gif [49/167] Installing: /usr/local/mozilla/components/librdf.so [117/167] Installing: /usr/local/mozilla/res/rdf/document.gif [135/167] Installing: /usr/local/mozilla/res/rdf/folder-open.gif [140/167] Installing: /usr/local/mozilla/res/rdf/folder-closed.gif [142/167] Installing: /usr/local/mozilla/res/rdf/article.gif [2/5] Installing: /usr/local/mozilla/defaults/profile/search.rdf [3/5] Installing: /usr/local/mozilla/defaults/profile/panels.rdf [5/5] Installing: /usr/local/mozilla/defaults/profile/localstore.rdf [6/33] Installing: /usr/local/mozilla/defaults/profile/en-US/mimeTypes.rdf [19/33] Installing: /usr/local/mozilla/defaults/profile/en-US/localstore.rdf [22/33] Installing: /usr/local/mozilla/defaults/profile/en-US/search.rdf [25/33] Installing: /usr/local/mozilla/defaults/profile/en-US/panels.rdf As you see, panels.rdf are created double up, so is search and localstore. But not mimeTypes.rdf.

I'm not using the installer which is why I don't see this. I'm pinging some folks rightnow. Will post back if we come up with something. I think you might be on to something with the descrepency in the installer log with mimetypes.rdf

Yes there is an installer problem here. profile\defaults\mimeTypes.rdf was not being added to the packages! This only effects new profiles where we rely on the file being in the package so we can copy it over. Re-assigning. Sspitzer just gave me the patch. sr=mscott We need a r= for someone. I'll scrounge that up. Renominating for rtm because the fix is super low risk and it prevents users on linux from creating a new profile and adding helper apps. dark, thanks for your persistence on this!

code submitted by sspitzer, sr=mscott.

I checked this into the tip dark. So you should be able to try this out in the next nightly build on linux. We'll try to get permission to check it into the branch.

And thanks heaven for mscott. But what about all those other rdf files in en-US? Is there supposed to be a double set?

alecf gave the r=alecf, marking rtm+

rtm++

for a migrated profile, we don't create the ~/.mozilla/profile/en-US/*.rdf but for new profiles, we do. we should not be creating the en-US dir under ~/.mozilla/profile we should be doing this: get the current locale check if defaults/profile/<locale> exists, if so copy the contents to ~/.mozilla/profile if not, copy the contents of defaults/profile hmm, I wonder if our logic is busted, or if we are doing a recursive copy and not a copy of the files in the dir only. I'll open a bug on racham. this probably means bad things for non english locales. I'll start a bug on racham, and see the gang.

packaging changes now checked into branch and tip. thanks phil.

yep, I think we are messing up other locales. after this fix, the mimeTypes.rdf that ends up in .mozilla/<profile>/mimeTypes.rdf is the one for the defaults/profile/mimeTypes.rdf, and not the one from defaults/profiles/en-US/mimeTypes.rdf either that is because we have a bug, or we just use the default if the locale is en-US. not sure. I'll start a bug on racham.

Fixed and fixed.. the really fun part of this bug is that rat's nest of preferences js errors. But it would also be interesting to know why, if no mimeTypes.rdf exist - preferences WILL created one if one adds types manually, but with a syntax it itself isn't able to read.

#56590 is the bug about the extra en-US dir.

Verified fixed. There are still problems with adding helper applications, but the very fundament for adding any at all is now obviously fixed, mimeTypes.rdf again being present. Instead of morphing this one into obscurity I'll follow up on related problems in other bugs. For now filed bug 56650 (maybe related to bug 56760 -> bug 56779). As long as mozilla have problems seeing the local filesystem at all, it's a little hard to figure out what is really happening when it looks for plugins, helpers etc., so holding my horses till that is fixed. Thank you all for a rapid turnaround once the problem was recognized.

To soothe some nerves and confirming status with something concrete: I just added acrobat reader as helper app, and it worked. Not quite as expected though: If i add the %s that all helper app README's instruct to add after appname, the pdf file from web simply seems to download to /tmp dir and doesn't open. If i remove %s, moz spawns acroread, again opening the desired file. Potential "relnote" I guess. Will test more before i file this.