50914 - Helper application panel listing is blank, cannot add mime type when using old profile

Status: VERIFIED FIXED

(SeaMonkey :: Preferences, defect, P1)

Description

[shrirang khanzode]

Build:20000830m18, linux only

When I start the browser using a pre-existing profile and go to 
Edit|Preferences|Navigator|Helper Applications, I see a blank window.
Also, when I try to add a new mime type..after filling in the details, when I 
press the OK button, I see a dialog saying something like "mime type already 
exisits. Want to readd?" Pressing ok does not dismiss the dialog and there is no 
other option to dismiss it other than clicking on CANCEL or the 'x' button. The 
mime type, as a result, does ot get added.

This is working absolutely fine when using a new profile with y'day's and 
today's builds on linux.(2000083106m18).

Comment 1

[shrirang khanzode]

qa: self.

Comment 2

[Dave]

Confirming on 2000083106/Linux. No mime types are present and I can't add any.
However, upon renaming my .mozilla directory and restarting the browser, the
mime type text/html appears and I'm able to add a new mime type.

cc self

Comment 3

[matt]

I'm seeing this also.
Not sure what is causing the problem.
I've worked on trying to figure out what the problem is 
and have been spinning my wheels.   Need more info.

Comment 4

[johng]

Fnav triage team:
or helper apps, we need to be able to support any pre-defiend mime types, but
can live with out teh ability to edit or add new mime types.

Comment 5

[Scott MacGregor]

If you can't add pre-defined mime types then platforms like linux will never be
able to launch helper apps for anything. While on windows and mac we'll use
registery and internet config information, for linux this preferences panel is
the ONLY way a linux user has for adding helper applications to use for content.

Comment 6

[sairuh (rarely reading bugmail)]

that's bad. eg, on linux need to configure the helper app so that adobe's pdf
app will display pdf files (afaik :).

Comment 7

[johng]

nav triage team:
+, P2  For this edge case functionality, we jsut want to make sure it is not 
ugly.

Comment 8

[matt]

I can not get this to happen.
Does anyone have a testcase?

Comment 9

[Dave]

I think the only way to reproduce this bug is to make a clean install of a
pre-helperapps-fix (I.e. before the original "helper apps are blank" bug was
fixed) nightly and then upgrade to a build which includes the fix. Something in
the old ~/.mozilla directory seems to be messing up the fix...

Comment 10

[Dave]

I'll attach my old .mozilla directory which still causes the helper apps to be
blank. Just back up your ~/.mozilla directory and replace it with this one to
reproduce the bug.

Comment 11

[Dave]

Ok, I guess you can't attach a directory :) and I'm not sure which file in the
.mozilla directory is causing the problem (assuming it's only one file) so I
can't attach that. I'll do some more research and see if I can't figure it out.

Comment 12

[matt]

Can you attach your mimetypes.rdf and .mime.types file?

Comment 13

[Dave]

Attachment: .mime.types file from my home directory

Comment 14

[Dave]

Attachment: mimeTypes.rdf from my old ~/.mozilla/default directory

Comment 15

[matt]

So i've downloaded this file and it works for me.
I'm really not sure what the problem is but it seems like
it is a migration problem.   I think if approperiate files
deleted this will start worksing.  I'm just not sure which file
is affecting this.

Comment 16

[Dave]

Mine also started working after I renamed my .mozilla directory and installing a
build which includes the fix.
However, replacing my working mimeTypes.rdf files with the old non-working one
makes the problem reappear. I don't know what the trouble is either but it's a
minor one which no one will see unless they've been testing nightly builds since
before the patch for the original bug made it in.
The severity and priority on this bug can probably be reduced quite a bit.

Comment 17

[matt]

So I'm asking this to be reviewed again and have the nsbeta3 taken off 
since this is only when upgrading on one of the daily builds.
The workaround if you happened to be doing daily builds
is to delete your mimeTypes.rdf file.

Comment 18

[Phil Peterson]

If matt's right that this is only when upgrading daily builds, then we don't 
need to fix it for nsbeta3.

Comment 19

[R.K.Aa.]

blank here too. deleting mimetypes.rdf doesn't help - i can add but can't see
them in prefs.

Why, btw, is the word "application" seemingly always trunkated to "pplication"
in mimetypes.rdf?

sample:

<RDF:Description about="urn:mimetype:pplication/pdf">

<RDF:Description about="urn:mimetype:handler:pplication/pdf">
---

and why isn't path to an application honored?

see bug 53056 for some more headaches.

Comment 20

[sairuh (rarely reading bugmail)]

the workaround doesn't help me for migrated profiles --for some reason such a
profile doesn't even include a mimeTypes.rdf. cc'ing gbush and dbragg to see if
this (ie, mimeTypes.rdf not being created for migrated profiles) is a known
issue. if so, pls let me know the bugid there.

Comment 21

[sairuh (rarely reading bugmail)]

could this be possibly fixed for RTM? unable to add types (and a blank helper
app listing) in a *new* but *migrated* profile quite bad...again, for all i know
what am seeing might be a profile manager issue. (btw, i haven't recently seen
this problem with existing, non-migrated profiles.)

Comment 22

[Dave]

Re: missing mimeTypes.rdf file.

 I had a problem when installing build 2000092013/Linux at home. I got the
 simptoms from this bug and noticed that I didn't have a mimeTypes.rdf file. I
 did, however, find a mimeTypes.rdf file in my ~/.mozilla/default/en-US
 directory. Moving this file down into my ~/.mozilla/default directory fixed the
problem.

Comment 23

[sairuh (rarely reading bugmail)]

for some reason i don't have a ~/.mozilla/default/ directory... although i do
have the [install_dir]/defaults/profile/ directory which does contain a
mimeTypes.rdf.

observation #1: after i had failed to add a new type [then quit the browser], i
noticed that a mimeTypes.rdf *was* created in the migrated profile directory.
however, upon a subsequent startup, the file listing remained blank.

observation #2: i quit the browser yet again, and decide to copy over [overwite]
using the mimeTypes.rdf from [install_dir]/defaults/profile/. result: list is no
longer blank, and i can add types!

(thx, Dan Vanbalen --your comment poked me towards a workaround. :)

now, why this bug occurs is still a mystery. from the new migrated profile, it
seems like mimeTypes.rdf from [install_dir]/defaults/profile/ should be copied
over during migration to avoid this problem. would that be a do-able/reasonable
fix?

now to see if *this* workaround helps bug 53870...

Comment 24

[R.K.Aa.]

seems to me that mimeTypes.rdf is created in the wrong dir on a fresh install?
landing in ~/.mozilla/default/en-US/ instead of in ~/.mozilla/default

So initially the mimetypes prefs are blank. But copying mimeTypes.rdf from the
en-US dir and do default and restarting, and suddenly the mimetypes can be seen
in prefs.

However: if i don't do this copying and start adding mimetypes on my own, they
will not show up: a mimeTypes.rdf is created in ~/-mozilla/default then, but it
seems to lack some lines and syntax - it's an incomplete file.

Having added mimetypes to the proper file (copied over) things still don't work
very well, however; can't make pdf or mp3 or any helper app trigger if i stand
on my head here. Some of the "old" syntax (adding a %s) seems to be redundant
now and i will succeed ONCE if i omit that, but the whole helper app stuff is
pretty much horked.

Comment 25

[WanSLenowski]

Using build 2000093006 for linux I copied ~/.mozilla/default/en-US/mimeTypes.rdf
to ~/.mozilla/default/mimeTypes.rdf as suggested and I was able to add new
mimetypes.  Also, I used the full path in the "Application to use" field with
no additions.  Example "/usr/local/bin/realplay".  I've added mimetypes for
realplayer files and mp3 files and everything works correctly.  The only
problem I had was clicking on a realplayer file that wasn't streamable.  After
clicking on the link the file would download with no feedback from mozilla,
open up realplayer and play the file.  I did have one other problem, however, I
believe this isn't mozilla specific.  When clicking on various links to stream
mp3's at www.mp3.com I was continually sent to a "problem diagnosis" page, even
though my mimetypes are set correctly.  This also occurs in netscape navigator
4.75.  I was able to get the streams to play by dragging the links into the
url box.

Comment 26

[sairuh (rarely reading bugmail)]

i can repro this on winNT, so marking this all and removing pp.

Comment 27

[don]

Sending this over to the profile migration folks to see if they want to fix it
ro RTM.

Comment 28

[Jerry Peek]

I'm doing this from memory; sorry if I've got the details a bit wrong.  I hope
this info, even though it might be a bit wrong, might help you troubleshoot.

BACKGROUND: I'm using build 2000080712; I depend on my browser and don't want
bleeding-edge crashes so I'm reluctant to get daily builds.  (Should I be?)
Yesterday I clicked on a link in a web page that should launch my RealAudio
player.  Instead I got a dialog that said something like "Don't know what
application to use for this type."  I clicked the "pick an application" button
(or whatever it was called) and got an error that said pickapp hadn't been
implemented yet.

WHAT HAPPENED: I opened Edit | Preferences | Navigator | Helper Applications.
As I had before, I got a blank screen.  I clicked "Add" to add a new entry for
the RealPlayer.  I filled in all the fields and clicked "OK".  I *think* that
the four-field dialog (description, extensions, MIME type, app) didn't close and
I *think* that I got a JavaScript error in the xterm where I started mozilla.
But I do *know* that the list of applications stayed empty after that; I assumed
that no helped app had been added.  zi looked in Bugzilla and saw this was being
worked on, so I didn't make any comments.

An hour ago, I clicked another RealAudio link, expecting to get another error
dialog (that might allow me to save the content to a file).  I was surprised to
get a dialog that asked me if I wanted to use my realplayer; the application
path was there in a field; it was the same path I'd typed in yesterday.  So I
clicked the "OK" button but nothing seemed to happen; I think I got an error.
(Sorry, I forget.)  The same dialog (use realplayer, or save to file) stayed
open, and the radio button next to the /usr/X11R6/bin/realplay field was still
selected.  I clicked on that same radio button and then clicked OK again; *this*
time it worked and the RealPlayer launched.

The helper apps window is still empty when I bring it up (no apps listed).  But
I see that I have a ~/.mozilla/default/mimeTypes.rdf file and that the
realplayer is listed in it.  (There are also other listings... from previous
attempts to add helper apps, I think.  There seems to be a duplicate entry for
the realplayer, and also two entries for acroread, the Acrobat reader.)

If you need any info about my setup before I try one of the workarounds here,
please let me know ASAP.

Comment 29

[dbragg]

Sorry, this ain't a migration bug.  That's a red herring. From all the reports
it looks like mimetypes.rdf is the source of the problem.  Either it's getting
corrupted or put in the wrong location.  Either way you look at it mimetypes.rdf
(or anything.rdf) never existed in Nav 4.x so therefore it can't be migrated.
Another data point is that even if you're in Netscape 6 itself and you add a
mimetype it still doesn't work.  I don't see how that could be a migration problem.

The only possible exception to this might be some pref that the old prefs.js
(the one from 4.x) has that needs to be reset.  I don't know what the pref might
be and besides, the helper app code should be able to read the old pref (like
most of the rest of the program does) and either convert it or ignore it.

Reassigning back to Matt.  Sorry.

Comment 30

[sairuh (rarely reading bugmail)]

hm. just spoke with don, who thinks that what i'm seeing is not [this] original
bug, but rather a problem with defaults/profile/mimeTypes.rdf not being used
[when it should] when a given profile doesn't have its own mimeTypes.rdf. i had
seen this with migrated profiles...and now also see it when i create a new
profile and throw out its mimeTypes.rdf.

don is gonna see who should get this bug. mscott/anyone, is there an existing
bug for what i'm seeing now? thx!

Comment 31

[don]

Scott, please see Sairuh's previous comment.  I think there's a problem whenever
a profile doesn't contain a mimeTypes.rdf file.  It's not reading the defaults.
 I searched for some kind of duplicate bug on this, but I couldn't find any.
Are you the person that should get this?  'Cause my team is stumped.

BTW, this is really a very nasty bug for anybody who migrates from 4.x to 6.0.

Comment 32

[selmer (gone)]

Bhuvan, can you look into this?  One comment that looks relevant is that
mimeTypes.rdf may be getting put into the en-US directory and therefore is not
found by profile manager.  (Leaving mscott on the CC)

Comment 33

[Chris McAfee]

*** Bug 55732 has been marked as a duplicate of this bug. ***

Comment 34

[racham]

I will take a look at this bug.
Adding Tao to the cc list. Tao had worked on creating default profile files
folder while working on localizations effort.

Comment 35

[racham]

Migrated profiles needed to copy some files exclusively from the default
location. mimeTypes.rdf happens to be one of those files. That's why we all new
profiles doing the right thing and migrated profiles not.

Will post the patch in the next update. Scott, please review the patch.

Comment 36

[racham]

Attachment: patch to copy mimeTypes.rdf file into the migrated profile dir

Comment 37

[racham]

making it rtm+.

Comment 38

[Scott MacGregor]

nice catch Bhuvan. sr=mscott

Comment 39

[Michael La Guardia]

marking rtm++

Comment 40

[racham]

Fixed (branch && trunk).

Comment 41

[shrirang khanzode]

I will need help here in verifying this bug since many people have added their 
issues here. Pls check and confirm that they are really fixed. I will check this 
on linux and comment.

Comment 42

[R.K.Aa.]

in SEA 2000101109 linux nothing is fixed, but perhaps the fix isn't in that
build yet?

Comment 43

[sairuh (rarely reading bugmail)]

using opt comm branch bits on linux [2000.10.11.09-n6], i no longer get a blank
mime type list in the Helper App panel --i'm also able to add new mime types.
tested with an existing profile, a new profile, and also a migrated profile.

shrir, how does this look for you on mac and win32?

fwiw, i used the installer for the build.

rkaa, seems like it shoulda gotten into your build. very odd.

Comment 44

[shrirang khanzode]

Attachment: mimetypes.rdf created with Pr2

Comment 45

[sairuh (rarely reading bugmail)]

just grabbed a commercial trunk build [2000.10.11.08] on linux, and this works
for me using a new profile, an existing profile and a migrated profile... again,
i used the installer bits.

rkaa, could you try this using the installer (well, to satisfy my curiosity ;)?

i've just used the SEA [mozilla trunk 2000.10.11.08] on linux, and here's what
i've found:
1. no problem using a freshly migrated profile. weird side note --while a
~/.mozilla/sairuh dir *is* created, the migrated profile "sairuh" does not
appear in the profile manager when i start via ./mozilla -ProfileManager.

2. does NOT work when using a freshly created, non-migrated profile --i
encounter this bug/or a variation of it, ie, bug 55732.

Comment 46

[sairuh (rarely reading bugmail)]

hm, now that i think of it, the SEA does use the installer --so am not sure if
using the labelled "installer" bit would make a difference for rkaa (unless i'm
wrong there, heh). hrm...i don't know if it'd be possible for the fix to make it
only into the commercial tree *shrug*...

off to more testing...

Comment 47

[racham]

There are couple of things that we need to be aware of here...

* With the fix that went in yesterday, all migrated profiles with this today's
builds should have mimeTypes.rdf file.

* Any new profile that is created will have the right mimeTypes.rdf file too.

* People who are still reporting the problem are the ones that have a old
profile and they have a bogus mimeTypes.rdf file. I noticed this on Shrirang's
machine (he attached a copy of that too in this bug report). So, the only way to
fix that situation is to just grab new mimeTypes.rdf file from defaults/profile
folder and put it in your profile directory. deafaults/profile folder is located
under
 <install dir>/Netscape 6 (on windows), <install dir>/Netscape Folder (on mac)
and <install dir> (on linux). (OR simply search for mimeTypes.rdf file under
your install dir, you will find one). You have to do all this if you insist on
using the old profile you have. Otherwise, you can simply delete that profile
and create a new profile and things should be fine.

* Also some of your old migrated profiles might not have any mimeTypes.rdf at
all. This bug fixed that situation but only for all upcoming migrated profiles.
So, If you have already migrated prior to this fix, please follow the steps I
have mentioned above to copy default mimeTypes.rdf file into that profile directory.

Incase if any of you don't know where profiles are located by default :
_______________________________________________________________________
Windows :

# Windows 2000  : C:\Documents and Settings\<user name>\Application
Data\Mozilla\Users50

# Windows NT     : C:\Winnt\Profiles\<user name>\Application Data\Mozilla\Users50

#Windows 95,98
    if password protection is disabled : C:\Windows\Application Data\Mozilla\Users50
    if password protection is enabled  : C:\Windows\Profiles\<user
name>\Application Data\Mozilla\Users50

Mac :

<Mac hard disk>:Documents:Mozilla:Users50

Linux :

$HOME/.mozilla

_______________________________________________________________________

Scott, please add anything I missed. This should probably go into release notes
too. 

Comment 48

[sairuh (rarely reading bugmail)]

i repeated what i did above [2000-10-11 16:09], except that i used the SEA for
the commercial trunk bits [2000.10.11.08]. (just to be clear, i had moved the
pre-existing ~/.mozilla dir prior to installation, both here and above at
2000-10-11 16:09.) the results differed, which makes me think the mozilla tree
[trunk at least] didn't get the fix. that, or rkaa and i are encountering
another bug altogether (bug 55732).

results:
1. for a freshly migrated profile, no problems. *moreover*, the profile name
*did* appear in the Profile Manager window (when using ./netscape
-ProfileManager).

2. no problem viewing the mime list or adding a mimetype for a freshly created,
non-migrated profile.

Comment 49

[R.K.Aa.]

2000101109

I deleted .mozilla dir in my homedir.
I deleted .mozilla dir in root dir
I installed mozilla (SEA) in /usr/local/mozilla (previous installation deleted)
I started mozilla and all it's components as root - once - or else nothing runs
very well as normal user.
I then quit moz as root and started it as normal user.

After this:
No mimeTypes.rdf is then found in /home/dark/.mozilla
No mimeTypes.rdf is found in /home/dark/.mozilla/default
There IS a mimeTypes.rdf found in /home/dark/.mozilla/default/en-US

Is it me who do something wrong here?

Comment 50

[R.K.Aa.]

SEA 2000101113 from scratch: same thing.
Is there some "netscsape -profilemanager i should run in addition?
Perhaps i DO something very wrong here: I never run any command like that, i
only start mozilla with a "mozilla" from command-line, also first time i start it.

Comment 51

[shrirang khanzode]

Works for se/myself. Verified fixed on branch linux 10/12. Adding vtrunk to get 
verified on the trunk.

Comment 52

[shrirang khanzode]

vtrunk 

Comment 53

[shrirang khanzode]

verifed on trunk (linux 10/27). Helper App panel no longer appears blank and 
can add mime type. marking as such. removing 'vtrunk' keyword.

Comment 54

[shrirang khanzode]

*** Bug 58487 has been marked as a duplicate of this bug. ***

Comment 55

[uamjet602]

Hmm.. well this was in the wrong component (browser-general), that's why I
didn't find it. When I noticed this problem there was someone in the #mozilla
irc channel with the same problem.

Changed component to preferences.

Notice that after removing the mimeTypes.rdf file I got a new one, but it still
didn't work. Only after creating a whole new profile it worked.

Perhaps there should be something in the release notes about this.

Comment 56

[shrirang khanzode]

*** Bug 58348 has been marked as a duplicate of this bug. ***

Comment 57

[shrirang khanzode]

*** Bug 61686 has been marked as a duplicate of this bug. ***

Comment 58

[shrirang khanzode]

*** Bug 58936 has been marked as a duplicate of this bug. ***

Comment 59

[Paul Chen]

*** Bug 64405 has been marked as a duplicate of this bug. ***

Comment 60

[R.K.Aa.]

*** Bug 73589 has been marked as a duplicate of this bug. ***