54940 - must define list of default MIME type associations for Helper Apps Preferences

Status: NEW

(Firefox :: File Handling, defect, P3)

Description

[ekrock's old account (dead)]

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.

Comment 1

[ekrock's old account (dead)]

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.

Comment 2

[ekrock's old account (dead)]

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.

Comment 3

[ekrock's old account (dead)]

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.

Comment 4

[matt]

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

Comment 5

[don]

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

Comment 6

[johng]

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?

Comment 7

[sairuh (rarely reading bugmail)]

*shrug*

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

Comment 8

[Scott MacGregor]

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.

Comment 9

[ekrock's old account (dead)]

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" 

Comment 10

[James Salsman]

> 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!

Comment 11

[Scott MacGregor]

mozilla\exthandler

Comment 12

[johng]

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

Comment 13

[matt]

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

Comment 14

[selmer (gone)]

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.

Comment 15

[James Salsman]

> 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!

Comment 16

[Asa Dotzler [:asa]]

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

Comment 17

[Robert Williams]

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.

Comment 18

[Kathleen :Brade]

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

Comment 19

[Kathleen :Brade]

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

Comment 20

[Simon Fraser [no longer active]]

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

Comment 21

[James Salsman]

> 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.

Comment 22

[James Salsman]

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?

Comment 23

[Ben Bucksch (:BenB)]

> 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.

Comment 24

[Ben Bucksch (:BenB)]

> 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.

Comment 25

[James Salsman]

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?

Comment 26

[sairuh (rarely reading bugmail)]

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

Comment 27

[scottputterman]

marking nsbeta1-

Comment 28

[Blake Ross]

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?

Comment 29

[Aleksey Nogin]

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).

Comment 30

[Blake Ross]

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).

Comment 31

[selmer (gone)]

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?

Comment 32

[Simon Fraser [no longer active]]

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.

Comment 33

[sairuh (rarely reading bugmail)]

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

Comment 34

[Scott MacGregor]

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

Comment 35

[Aleksey Nogin]

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.

Comment 36

[Todd Pringle]

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

Comment 37

[Bill Law]

Nope.

Comment 38

[Todd Pringle]

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?

Comment 39

[Aleksey Nogin]

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?

Comment 40

[sairuh (rarely reading bugmail)]

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?

Comment 41

[Aleksey Nogin]

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.

Comment 42

[Steve Koppelman]

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.

Comment 43

[Aleksey Nogin]

> 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.

Comment 44

[Steve Koppelman]

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.

Comment 45

[sairuh (rarely reading bugmail)]

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.

Comment 46

[Peter Trudelle]

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

Comment 47

[Bill Law]

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.

Comment 48

[Steve Koppelman]

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.

Comment 49

[Bill Law]

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.

Comment 50

[Bill Law]

Not today...

Comment 51

[Bill Law]

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

Comment 52

[Steve Dagley]

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.

Comment 53

[Ben Bucksch (:BenB)]

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.

Comment 54

[Peter Lubczynski]

Plugins also really need a way override associated mime types.

Renominating nsbeta1 and making this as blocking the plug-in manager bug 19118.

Comment 55

[Peter Trudelle]

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

Comment 56

[sairuh (rarely reading bugmail)]

nominating

Comment 57

[Samir Gehani]

Nav triage team: nsbeta1+/adt3

Comment 58

[Torben]

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

Comment 59

[Samir Gehani]

Nav triage team: nsbeta1-

Comment 60

[Boris Zbarsky [:bzbarsky]]

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

Comment 61

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates.
:Gijs, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 62

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.