Closed Bug 55732 Opened 24 years ago Closed 24 years ago

can't add helper application

Categories

(SeaMonkey :: Preferences, defect, P3)

Product:
SeaMonkey
Component:
Preferences
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: spam, Assigned: mscott)

Details

(Keywords: regression, Whiteboard: [rtm++])

Attachments

(1 file)

proposed changes to add mimeTypes.rdf to the package lists.
1.54 KB, patch
Details | Diff | Splinter Review 
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.
Severity: normal → major
Keywords: regression
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.)
Keywords: rtm
QA Contact: sairuh → shrir
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 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
verified.
Status: RESOLVED → 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 ;).
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
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.
Whiteboard: [rtm-]
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!
Assignee: matt → mscott
Status: REOPENED → NEW
code submitted by sspitzer, sr=mscott.
Status: NEW → ASSIGNED
Whiteboard: [rtm-] → [rtm need info] 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.
Whiteboard: [rtm need info] sr=mscott → [rtm need info]
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+]
rtm++
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
~/.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.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 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
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.
Status: RESOLVED → VERIFIED
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.

Attachment

General

Creator:
Created:
Updated:
Size: