Using Commercial 2000093008 on WinNT 4.0 SP4. To repro: 1) Edit-->Preferences 2) click "Helper Apps" Only two default MIME-type-to-helper-app associations are listed (one for PDF to Adobe, the other for HTML which presumably starts a Navigator window). Granted, we've never committed to have a default association of all known MIME types to all known plug-ins (or anything like this), but shouldn't there be more than two defaults registered here? Having only two listed seems suspiciously low. How many defaults did we have registered in Nav4? Shouldn't some defaults be included for plug-ins bunded with Netscape 6 such as Flash? (maybe Flash is a bad example as it's a pure plug-in, not a helper app) If we register the PDF association by default, why not others such as RealPlayer? What are the criteria that determine which helper apps appear on this list? Opening this bug for investigation to make sure that we're doing the right thing for RTM.

Marking 4xp and nominating rtm to put on RTM radar until we either fix this or convince ourselves that there's no problem here. cc:ing johng Navigator PM who handles RealPlayer relationship.

Additional info: I'm using a "created from scratch way back when (Fall '99?)" Netscape 6 user profile, not one that was migrated from Nav4. Perhaps if you create or migrate a profile now you get more default associations? To see the impact on user experience of this bug, visit http://oreilly.linux.com/pub/a/linux/2000/08/04/rt.html and click the RealAudio image link to launch the clip. My legendarily-horked PC (which I'm rebuilding this week) may be causing part of the problem. Even though I have RealPlayer G2 on my system, for no reason I can discern both Nav4 and N6 are starting an old copy of RealPlayer 5.0 when I click the link. Perhaps my Windows app registry has been corrupted or the old association with RealPlayer 5.0 has somehow be restored? That shouldn't change the # of helper apps listed in the helper apps prefs by default however.

OK, after manually restoring the MIME type association in both Nav4 and N6, both of them launch RealPlayer G2 as they should, so fortunately our helper app association editor UI and launch code are working fine. This bug should focus on the question "what should the Helper Apps Preferences list by default, and are we listing that?" Sorry if this turns out to be an INVALID--I just want to make sure we don't overlook something important here.

We decide we would include all the helper apps selected in 6.01. John....?

Re-assigning to John so he can get Matt and I the information.

Sairuh, can you help us answer 2 questions: 1) What mime type associations shipped in 4.x? 2) What mime type associations were include in PR3?

*shrug* shrir/mscott, could you please answer johng's questions above? thx! (i'd like to know, meself. ;)

PDF and HTML showed up in early builds because I put those two mime types in there for testing purposes and they went out in beta2 by mistake. They are totally bogus. And new profiles (after beta2) don't have the PDF entry anymore. I cleaned that up. So currently, NS6 ships with NO default helper apps pre-loaded. On windows and Mac, we have windows registry and IC integration support so anything already registered with the OS will work for us. However, we don't reflect these settings in the prefs UI. That bug was futured a long time ago. i.e. OS mime information is no longer reflected in the helper app prefs panel like we did in 4.x. So the question is really, does marketing have contractual agreements where they need mime types pre defined for certain applications. We can add those kinds of mime types to the mimeTypes.rdf file that a user gets when a profile is created.

So it sounds like most of the MIME type associations I was seeing in looking at Nav4 prefs were (a) explicitly registered by plug-ins at install time by the plug-in installer, or (b) reflections of OS MIME type associations--something we're not doing for RTM. I don't fully understand this list or what its functional significance is. IIUC, Navigator uses this list to: 1) decide which plug-in or helper app to invoke when it downloads a page with a given MIME type (e.g. a link on an HTML page points to a .rm file, so Nav looks at the list and knows to launch the RealPlayer helper app in its own window) 2) decide which plug-in to invoke when content within a web page (embedded via an EMBED or OBJECT) specifies its own MIME type (e.g. "Here's an EMBEDded realplayer file--should I use the RealPlayer plug-in or the Windows Media Player plug-in [is that usable as a browser plug-in as well as as a helper app in its own window?] to execute/display it) 3) associate filename extensions to plug-ins/helper apps (When is this filename association info used? for guessing what plug-in/helper app to invoke when you open a file through the File-->Open dialog with a given extension? e.g. if you open a PDF file through File-->Open ... is that even possible?) Sounds like our policy on registrations here for Netscape 6 RTM should be: 1) Plug-ins/helper apps *not* bundled with Netscape 6 are entirely responsible for making sure that their installer registers them in this list when it runs. 2) However, if the plug-in/helper app *is* bundled with Netscape 6, I think we have to hard-code this registration info ourselves since the given plug-in's installer never runs. Am I correct about that? Or does the N6 installer recursively invoke the RealPlayer/Flash installer binary, which then has a chance to register itself? We need to determine the answer to (2), whether we have to hard-code this. If so, John as Navigator PM or needs to review the list of which plug-ins we bundle in which configurations and find out from the partners what data we need to have registered for them. For safety, I think that someone should also go through the whole list of plug-ins/helper apps they see listed in a well-loaded Nav4, think about the functional significance of each registration, and make sure we're not overlooking some entry that is necessary for Navigator to work correctly. Changing summary from "default Helper Apps Preferences only has two MIME type associations" to "must define list of default MIME type associations for Helper Apps Preferences"

> On windows and Mac, we have windows registry and IC integration > support so anything already registered with the OS will work for us. Please tell me where in the code that is done. Thanks, Scott!

mozilla\exthandler

once again, we want the mime type list in Netscape 6 to match what we had in 4.x unless there is any objection. That should include real player and flash and whatever else is included in 4.x. reassignign bug back to component owner

This isn't a front end problem. The problem is we are not getting them added in the mimetypes.rdf file.

rtm-. In actual fact, registered applications will work fine (according to the comments in this bug.) It's only if you go look at the associations UI that you would wonder what's going on. Since the bug to expose the underlying OS info into that UI was futured, I don't see that fixing this has significant benefit. If the bundled apps don't launch correctly, that's a different bug and you should file it.

> Since the bug to expose the underlying OS info into that UI was futured Which bug was that, please? I want to get cc:ed on it so I stand a chance of understanding the helper app database accesses. Thank you!

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

selmer says apps work fine, but that's actually not (always) the case. bug 60524, which is listed as a duplicate here, is related to 60525, which points out that jar files aren't handled, and can't be added.

Lots of users seem to expect to see all of their helper applications / mappings listed in the corresponding preferences panel. Is it only Macintosh users who are confused by this empty mapping table (including myself) or are lots of our users confused? Here are some comments from http://www.macintouch.com/netscape6.html: from Scott Synder (11/15/2000): Annoying: No helpers mapped. I would have to create every helper application map from scratch. from Jason Beach (11/15/2000): As someone else mentioned already, the Helper Application section of the preferences is alarmingly empty. Netscape still appears to know which apps to use (i.e. stuffit expander for .sit files), but it brings up a dialogue asking which app you'ld like to use every time you download (ala Windows). from Jason Alcock (11/15/2000): NO application helper settings by default. This is a serious oversight. ... doesn't allow the user to use it properly (no helper apps) from Deborah A. Levinson (11/16/2000): Helper applications list is completely cryptic. Netscape is definitely reading my plug-ins, not that I have any idea how to change which plug-in handles which mime-type anymore. from Dale Headrick (11/16/2000): Where are all the Helper Apps? from Jacob Arnold (11/14/2000): I can't figure out what Netscape 6 uses to determine helper apps

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

Shouldn't this be Mozilla 0.9, and higher priority?

> Shouldn't this be Mozilla 0.9, and higher priority? Yes, I think so. I still don't fully understand the code, but I think the problem is that just because the underlying OS can launch a helper app given a media type (as is done in the exthandler code) doesn't mean that all the fields in the mimeTypes.rdf helper app database can be populated. Scott, is that a correct assessment of the hold-up on this? If so, I propose that the human-readable strings for such associations be set to something like "Helper app provided by operating system type registration" and similar dummy values be used in the missing fields. Will that make this doable, Scott? Do you agree with that solution, Eric? It would be great if all the helper app and mimeType RDF database fields got documented.

Could this be accomplished by copying the constant tables in http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsExternalHelperApp Service.cpp to the default prefs file in http://lxr.mozilla.org/seamonkey/source/profile/defaults/mimeTypes.rdf and if so, would the default prefs file have to be different for each OS?

> On windows and > Mac, we have windows registry and IC integration support so anything already > registered with the OS will work for us. While it might "work" on Win and Mac, it doesn't on Unix, because of bug 52441. > However, we don't reflect these > settings in the prefs UI. That bug was futured a long time ago. i.e. OS mime > information is no longer reflected in the helper app prefs panel like we did > in 4.x. Which bug is that? I didn't find it. On Win and Mac, we should at least add some UI text noting that.

> So the question is really, does marketing have contractual agreements where they > need mime types pre defined for certain applications. Please file a Netscape-only bug about that.

Ben B.: I know you think that this does not block bug 58811 in a "hard" sense, but as a matter of good design and reasonable programming practice, shouldn't condsideration of this underlying data be given sufficient treatment before all the decisions as to how it will accessed are made? Also, someday someone may want to add new fields to the mimeTypes.rdf schema, perhaps for extra information concerning helper input applications (as opposed to ordinary display/output helper apps) for enhanced file upload. If at this stage the design is done haphazardly, schema changes will be much more difficult later on. Eric K.: There are almost always going to be two MIME helper application association databases: the OS's and mimeTypes.rdf's. This bug can be resolved as long as there is no question that the mimeTypes.rdf preferences are going to be searched first. Then it is only a matter of editing the profile/defaults/mimeTypes.rdf -- although that will have to be done by platform-dependent installer code to find the right pathnames, but at least it's a clear task. Scott M.: mimeTypes.rdf is consulted before the OS registrations in the exthandler code, right?

gah, this fell off my radar --nominating for beta1.

marking nsbeta1-

How could this be nsbeta1-? Based on public user and reviewer feedback about 6.0, this was one of the most annoying and confusing parts of the product. Aside from the url Kathy provided, cf. http://www.macfixit.com/ultimate/Forum21/HTML/000032-2.html Where's the futured bug that keeps getting referenced here about not reflecting the list of mime types in the UI (it's not showing up in my queries, and BenB couldn't find it either), and why is it futured? Why is this oft-complained about bug slipping from release to release?

I think that this bug, or at least the Linux part of it is actually a duplicate of bug #52441. As long as Mozilla can deduce the proper helper apps by reading the configuration files that already exist in the system, there is no need for Mozilla to have it's own list (which has less chances of working correctly on a particular system).

The most common user complaint I see is not that the app doesn't properly recognize the helper apps associated with certain mime types, but that the UI for adding and editing helper apps is completely busted (and also doesn't reflect the correct list of helpe rapps).

Seems like the main hurdle here is that we don't want to add all the code to allow the user to edit the entries that came from the registry. Why not make them "read only" but still show them in the UI? Would that be simple enough to get into this milestone?

It would be trivial (on Mac) to add a button to take the user to the OS-specified settings. We should do this, and add some verbage on that prefs panel to say where the data are coming from.

mscott, how difficult would it be to do what selmer suggests for unix/linux?

pretty hard. there are no linux hooks into the OS for getting mime type information....every flavor of UI has it's own thing.

As I said, I believe that bug #52441 already asks for what would be the right thing on Linux - to read the global and user's mailcap and mime.types files.

Bill, are you planning on covering this in your helper app work? I know we've talked about it in the past.

Nope.

Can we at a minimum populate this ourselves with data for default mime type associations we know about, especially for the helper apps we ship with such as RealPlayer? Beyond that, users would have to edit/add other entries manually. This would at least be some forward progress for 6.5 and make some of our partners happy. How hard is that mscott?

Is this bug asking the same thing as bug #52441 asks for a Linux and bug #68514 on Mac (e.g. be able to get the list from the OS settings) or is it asking for some default list to be distributed with Mozilla?

adding dependencies for platform-specific issues already filed. bug 52441 covers linux bug 68514 covers mac os [also see bug 68515 for further commentary] is there perchance a platform-specific bug out there for win32-defined handlers?

Sorry fo the spam, but there are so many strage dependencies among the helper app bugs that adding new ones without creating loops becomes increasingly hard.

You're making a big mistake. mimeTypes.rdf is not only used for picking helper apps and plugins for inbound content. It's also used every time a file is attached to an outbound mail/news message. Without a comprehensive list of mimetype-to-file-extension mappings, file attachments sent by a Mozilla/NS6 user won't open properly at the receiving end. Let me say this as clearly as possible: while it would be "nice" to inherit helper app and plugin mappings from the OS or from NS4 settings, it is _critical_ that the mimetype-to-file-ext mappings are present, even if no helper app is defined. This list should ensure coverage of all reasonably mainstream filetypes, including office suites (.doc, .rtf, .xls, .ppt, .sdw, .123 et al.), media formats (.qt, .avi, .mov, .cgm, .wmf, .ram, etc.) and compression formats (.zip, .gz, .tgz, .tar, .arj, .bz2 and so on) among many many others. See NS4's mimetypes for what is no doubt fodder for a painless conversion to RDF. Please remember that all common (and uncommon) file extensions must be covered in this process on all platforms, even when the platform doesn't support the file format. The purpose is to ensure that users of any platform can properly _send_ all known filetypes to other people. Without the mappings on the sender's side, an attachment isn't handled properly on the receiving end.

> You're making a big mistake. Who is making a mistake? As for outbound context, at least on Linux mime.types gives a mapping of extensions to mime types.

If the Linux builds do check local mime.types for this, it at least seems to ignore /etc/mime.types if a (much less useful and very incomplete) "Netscape"-generated ~/.mime.types is present in $HOME. I'm still skeptical that this works at all, though. When I send an .rtf file as an attachment, it goes out as text/plain inline . No entry in mimeTypes.rdf, no entry in ~/.mime.types, but there is an entry (as application/rtf) in /etc/mime.types. Furthermore, my attempts to attach a .doc also go out as 7-bit text/plain inline, and in this case there _is_ an entry in ~/.mime.types mapping .doc to application/msword. So for me, anyway, both with an imported NS4 profile and with a fresh one, it doesn't do what you or I expect it to do, and doesn't seem to honor the old-school "Netscape" $HOME/mime.types or the system default /etc/mime.types ...which have different formats, it should be noted.

nominating for moz0.9.6. peter, is there someone in your group who'd be working on this? just wondering if this should be reassigned... [bill? ben? samir? bueller?] this could nicely complement bug 19118: plug-in manager ui.

Sounds like this should be addressed as part of improving helper app management, but I'm not sure how much we can afford to do about it. I think this has traditionally been of more interest to mail, perhaps they can help with it? ->law, 0.9.6

This work will not be completed in mozilla0.9.6. I think the MachV feature described at http://www.mozilla.org/xpapps/MachVPlan/HelperAppMgt.html may be of interest to those who care about this bug. Basically, that feature is the fix for this bug.

Just to be clear all the bases are covered: The project manifesto at http://www.mozilla.org/xpapps/MachVPlan/HelperAppMgt.html does _not_ mention the use of mimetypes mappings in message composition in mailnews. Please be sure that the mimetypes are referenced and used when attaching files to outbound messages. When I last checked this was still very much broken on Linux, and all attachments went out as inline text/plain; not sure about current status on other platforms.

Resetting target milestone for all "window integration" bugs to mozilla0.9.8. I'm working on performance and won't get to that till next milestone.

Not today...

Setting target milestone to match the bug that was being used to track this feature (bug 106074).

Just so everybody realizes the Mac OS X implications of not having helper app UI in Mozilla/N6... There is no UI for editing the Internet Config database of helper app mapping provided by Mac OS X (as there is via the Internet control panel under Mac OS 9). Without a UI to edit this in Mozilla/N6 we are left with recommending that the user that needs to change helper app mappings launch IE which does have an internal UI for editing helper app mappings. I'd hardly consider that an acceptable response and would strongly urge that adding this UI to Mozilla/N6 be considered a priority. If not XP, definitely for the Mac builds.

sdagley, I'm a bit confused. - This bug, as I understood it, is just about filling the *default* mapping with reasonable values. This is like already having a bookmark feature, but requesting that the default bookmark list has some reasonable entries in new profiles. - In my Unix builds, I do have working helper app management, under Prefs|Nav|Helper Apps, since years already.

Plugins also really need a way override associated mime types. Renominating nsbeta1 and making this as blocking the plug-in manager bug 19118.

nsbeta1- per Nav triage team, too late to get this in MachV, putting on radar for point release.

nominating

Nav triage team: nsbeta1+/adt3

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

Nav triage team: nsbeta1-

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