236 bytes, text/plain
3.31 KB, text/plain
1.63 KB, patch
|Details | Diff | Splinter Review|
2.28 KB, text/plain
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).
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
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.
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.
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.
that's bad. eg, on linux need to configure the helper app so that adobe's pdf app will display pdf files (afaik :).
nav triage team: +, P2 For this edge case functionality, we jsut want to make sure it is not ugly.
I can not get this to happen. Does anyone have a testcase?
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...
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.
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.
Can you attach your mimetypes.rdf and .mime.types file?
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.
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.
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.
If matt's right that this is only when upgrading daily builds, then we don't need to fix it for nsbeta3.
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.
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.
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.)
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.
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...
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.
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.
i can repro this on winNT, so marking this all and removing pp.
Sending this over to the profile migration folks to see if they want to fix it ro RTM.
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.
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!
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.
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)
*** Bug 55732 has been marked as a duplicate of this bug. ***
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.
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.
Created attachment 16689 [details] [diff] [review] patch to copy mimeTypes.rdf file into the migrated profile dir
making it rtm+.
nice catch Bhuvan. sr=mscott
Fixed (branch && trunk).
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.
in SEA 2000101109 linux nothing is fixed, but perhaps the fix isn't in that build yet?
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.
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.
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...
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.
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.
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?
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.
Works for se/myself. Verified fixed on branch linux 10/12. Adding vtrunk to get verified on the trunk.
verifed on trunk (linux 10/27). Helper App panel no longer appears blank and can add mime type. marking as such. removing 'vtrunk' keyword.
*** Bug 58487 has been marked as a duplicate of this bug. ***
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.
*** Bug 58348 has been marked as a duplicate of this bug. ***
*** Bug 61686 has been marked as a duplicate of this bug. ***
*** Bug 58936 has been marked as a duplicate of this bug. ***
*** Bug 64405 has been marked as a duplicate of this bug. ***
*** Bug 73589 has been marked as a duplicate of this bug. ***