This used to work, so adding regression keyword.
Severity: normal → major
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.)
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
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
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.
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
Created attachment 17097 [details] [diff] [review] proposed changes to add mimeTypes.rdf to the package lists.
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+]
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
Last Resolved: 18 years ago → 18 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.
You need to log in before you can comment on or make changes to this bug.