Open
Bug 54940
Opened 24 years ago
Updated 2 years ago
must define list of default MIME type associations for Helper Apps Preferences
Categories
(Firefox :: File Handling, defect, P3)
Firefox
File Handling
Tracking
()
NEW
People
(Reporter: ekrock, Unassigned)
References
(Depends on 3 open bugs, )
Details
(Keywords: helpwanted, Whiteboard: [adt3] se-radar)
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.
Reporter | ||
Comment 1•24 years ago
|
||
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.
Reporter | ||
Comment 2•24 years ago
|
||
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.
Reporter | ||
Comment 3•24 years ago
|
||
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....?
Updated•24 years ago
|
Re-assigning to John so he can get Matt and I the information.
Assignee: matt → johng
Whiteboard: [rtm need info]
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•24 years ago
|
||
*shrug*
shrir/mscott, could you please answer johng's questions above? thx! (i'd like to
know, meself. ;)
QA Contact: sairuh → shrir
Comment 8•24 years ago
|
||
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.
Reporter | ||
Comment 9•24 years ago
|
||
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"
Summary: default Helper Apps Preferences only has two MIME type associations → must define list of default MIME type associations for Helper Apps Preferences
Comment 10•24 years ago
|
||
> 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•24 years ago
|
||
mozilla\exthandler
Comment 12•24 years ago
|
||
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
Assignee: johng → matt
QA Contact: shrir → sairuh
Comment 13•24 years ago
|
||
This isn't a front end problem.
The problem is we are not getting them added in the mimetypes.rdf file.
Assignee: matt → mscott
Updated•24 years ago
|
QA Contact: sairuh → shrir
Comment 14•24 years ago
|
||
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.
Whiteboard: [rtm need info] → [rtm-]
Comment 15•24 years ago
|
||
> 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•24 years ago
|
||
*** Bug 60524 has been marked as a duplicate of this bug. ***
Comment 17•24 years ago
|
||
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•24 years ago
|
||
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
Keywords: nsmac2
Comment 19•24 years ago
|
||
*** Bug 60998 has been marked as a duplicate of this bug. ***
Comment 20•24 years ago
|
||
Shouldn't this be Mozilla 0.9, and higher priority?
Comment 21•24 years ago
|
||
> 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•24 years ago
|
||
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•24 years ago
|
||
> 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.
Keywords: mozilla0.9
Comment 24•24 years ago
|
||
> 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•24 years ago
|
||
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?
Blocks: 58811
Comment 26•24 years ago
|
||
gah, this fell off my radar --nominating for beta1.
Comment 27•24 years ago
|
||
marking nsbeta1-
Updated•24 years ago
|
Keywords: rtm → helpwanted
Comment 28•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
mscott, how difficult would it be to do what selmer suggests for unix/linux?
Comment 34•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
Bill, are you planning on covering this in your helper app work? I know we've
talked about it in the past.
Comment 37•24 years ago
|
||
Nope.
Comment 38•24 years ago
|
||
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•24 years ago
|
||
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?
Blocks: 78106
Comment 40•24 years ago
|
||
Updated•23 years ago
|
Comment 41•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
> 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•23 years ago
|
||
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.
Updated•23 years ago
|
Whiteboard: se-radar
Comment 45•23 years ago
|
||
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.
Keywords: mozilla0.9.6
QA Contact: shrir → sairuh
Comment 46•23 years ago
|
||
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
Assignee: mscott → law
Target Milestone: Future → mozilla0.9.6
Updated•23 years ago
|
Component: Preferences → File Handling
Comment 47•23 years ago
|
||
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.
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Comment 48•23 years ago
|
||
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•23 years ago
|
||
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.
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Comment 51•23 years ago
|
||
Setting target milestone to match the bug that was being used to track this
feature (bug 106074).
Depends on: 106074
Target Milestone: mozilla0.9.9 → Future
Comment 52•23 years ago
|
||
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•23 years ago
|
||
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.
Updated•23 years ago
|
Keywords: mozilla0.9.6
Comment 54•23 years ago
|
||
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•22 years ago
|
||
nsbeta1- per Nav triage team, too late to get this in MachV, putting on radar
for point release.
Updated•22 years ago
|
QA Contact: sairuh → petersen
Comment 57•22 years ago
|
||
Nav triage team: nsbeta1+/adt3
Comment 58•22 years ago
|
||
*** Bug 184870 has been marked as a duplicate of this bug. ***
Comment 60•22 years ago
|
||
*** Bug 153477 has been marked as a duplicate of this bug. ***
Updated•16 years ago
|
Assignee: law → nobody
QA Contact: chrispetersen → file-handling
Updated•8 years ago
|
Product: Core → Firefox
Target Milestone: mozilla1.2alpha → ---
Version: Trunk → unspecified
Updated•2 years ago
|
Severity: normal → S3
Comment 61•2 years ago
|
||
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.
Flags: needinfo?(gijskruitbosch+bugs)
Comment 62•2 years ago
|
||
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.
Flags: needinfo?(gijskruitbosch+bugs)
You need to log in
before you can comment on or make changes to this bug.
Description
•