can't add helper application



18 years ago
14 years ago


(Reporter: R.K.Aa., Assigned: Scott MacGregor)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: [rtm++])


(1 attachment)



18 years ago
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]

Comment 1

18 years ago
This used to work, so adding regression keyword.
Severity: normal → major
Keywords: regression

Comment 2

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

Comment 3

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

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.)
Keywords: rtm
QA Contact: sairuh → shrir

Comment 5

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

Comment 6

18 years ago
this looks like a dup of 50914, marking so.

*** This bug has been marked as a duplicate of 50914 ***
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Comment 7

18 years ago

Comment 8

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

Comment 9

18 years ago
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 ;).
Resolution: DUPLICATE → ---

Comment 11

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

Comment 12

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

Comment 13

18 years ago
Minus until someone else can reproduce this consistently.
Whiteboard: [rtm-]

Comment 14

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

Comment 15

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

Comment 16

18 years ago
From install log 2000101221:

[dark@localhost mozilla]$ grep mime install.log
Installing: /usr/local/mozilla/components/
Installing: /usr/local/mozilla/components/
Installing: /usr/local/mozilla/components/
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

How can this be a local error?

Comment 17

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

Comment 18

18 years ago
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/
[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.

Comment 19

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

Comment 20

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


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!
Assignee: matt → mscott

Comment 21

18 years ago
Created attachment 17097 [details] [diff] [review]
proposed changes to add mimeTypes.rdf to the package lists.

Comment 22

18 years ago
code submitted by sspitzer, sr=mscott. 
Whiteboard: [rtm-] → [rtm need info] sr=mscott

Comment 23

18 years ago
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. 
Whiteboard: [rtm need info] sr=mscott → [rtm need info]

Comment 24

18 years ago
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+
Whiteboard: [rtm need info] → [rtm+]

Comment 26

18 years ago
Whiteboard: [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
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.

Comment 28

18 years ago
packaging changes now checked into branch and tip. thanks phil.
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
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

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.

Comment 30

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

Comment 32

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

Comment 33

18 years ago
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.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.