68514 - Get default helper apps for *Extensions and Mime Types* from Launch Services

Status: REOPENED

(Firefox :: File Handling, defect, P3)

Description

[Andrew Thompson]

See Control Panels->Internet->Advanced->File Mapping

Dialog maps system wide support for protocols filename extensions and mime types 
(.mp3, image/tiff) etc to helper applications or plugins used to process that 
protocol.

Need to be picking up these settings and using them to handle all files 
downloaded with these mime types or extensions, that are not

i/ handled by the browser internally
ii/ handled by a plugin

(though the UI should allow this to be overriden as in IE and Nav4 on Mac OS)

This would imply *all* protocols (http, ftp) and all access methods, (following a 
link, "right click->save link  as" and typing the URL into the address bar should 
all work). The reason I mention this is that bug 43585 states there are multiple 
code paths and fixing one does not necessarily fix the others.

Comment 1

[Daniel Veditz [:dveditz]]

Paul has other bugs of this type; CC'ing sdagley

Comment 2

[Paul Chen]

Ack! Please, DO NOT confuse or amalgamate saving files and handling protocols
(mailto, http, ftp, telnet, etc). At any rate, we do traipse through the
Internet Config mapping database (File Mapping pref in Internet control panel on
Mac) when we save files via the nsExternalHelperAppService (and even more than
that now). Hell, I even fixed a bug for 6.01 that fixed the quicktime beta
download problem.

Using IC to get protocol helpers is a seperate bug, though I don't know where
that one went. Also, helper apps prefs in mozilla should override looking into
IC, if I'm not mistaken.

So I don't know what to do with this bug other than mark it as a dup of the use
protocol mappings (helper apps in IC-speak).

Comment 3

[Andrew Thompson]

Ooops. I should apologise, I just read what I wrote and its nonsense. I filed
this bug by copying and pasting from another one, and I didn't update the text
properly. I'd specifically wanted to untangle protocols from file mappings, and
I ended up achieving the opposite.

Here's what I'd like to achieve with this bug:

1/ State that file mapping should be applied *regardless* of the protocol used
2/ They should be applied regardless of the way the user initiates the download
in the interface (follow a link, "save link as", address bar)

Paul, your last comment in bug 43585 implied that this isn't currently true. If
you want a reminder bug on this, then say the word and I'll fix the summary.
Otherwise if this is already completely fixed close this out. 

The one thing you said I do have an issue with is wanting to get away from this
idea of Mozilla having its own layer of settings on top of Internet Config. This
isn't how Internet Config is supposed to work, its supposed to be *the* source
of mapping information for all applications.

This might be a UI discussion, in which case this is the wrong forum, but here's
the scenario I'm trying to avoid:

1/ User sets up TIFF documents to be opened in Graphic Converter using Internet
Config

2/ Mozilla picks up this preference, assocuates TIFF with Graphic Converter

3/ Later, user is browsing web, uses Mozilla preferences to change TIFFs to open
in Photoshop. Mozilla sets up Internet Config to match, but remembers it has its
own "custom" setting.

4/ Internet Config is now setup to open TIFFs in Photoshop, as is Mozilla. But
Mozilla thinks its own setting is special now.

5/ User changes TIFFs once more in Internet Config... but Mozilla now thinks it
knows better and ignores the setting. User curses!

My issue is that using Intenet Config works in step 1 but not in step 5, and
most users won't grasp why.

I can see 3 solutions

* Mozilla never writes Internet Config, only ever reads it - this is just as bad
because the user has to remember to make all changes in IC if they want to make
all applications the same (i.e. to the user, changes in Moz are ignored by other
applications)

* Mozilla has a really great UI which makes it plain as the day is long whether
its currently using the IC setting or its own setting (on a filetype by filetype
basis. The trouble with this is no matter how great the UI the user still has to
go and find the filetype in the huge list of filetypes in Mozilla's UI, check
what it is, and then alter the setting if they don't like it.

* Integrate the systems properly so Mozilla has no private helper apps
prefernces. Its either
   * handle by browser
   * handle by plugin
   * whatever internet config says to do

OK, I'm doing what I promised myself I'd never do again, rambling on in a bug.
This is the wrong forum. 

I believe its not Mozilla's job to override internet config for 99% if not 100%
of settings. Arguably the user should be able to change the handler for http to
be IE in internet config and Moz should dutifully open links in IE. 

If I'm not just a rambling maniac, perhaps the best idea is to take this to the
newsgroups and see if there's consensus...?

Comment 4

[Paul Chen]

nav triage team:

We don't have any more cycles to properly handle this issue. Marking nsbeta1-

Comment 5

[Viswanath Ramachandran]

nav pretriage: already minused. setting to Future. 

Comment 6

[Paul Chen]

Oy, just stumbled back onto this one triaging my "untriaged" bugs. We should
probably fix this the "right way" one of these days. MacOS X is even more
interesting since there is no system UI to change IC prefs; you gotta use IE. Gack!

Marking p2 and mozilla1.1

Comment 7

[sairuh (rarely reading bugmail)]

hm, this is blocking 54940, which is all platforms and currently set for, heh,
moz0.9.6... paul, is there anyone else who might be able to help you here?
cc'ing some mac folx in supplication. :)

Comment 8

[sairuh (rarely reading bugmail)]

trudelle to triage...

Comment 9

[Peter Trudelle]

Mass moving all of my open Nav/toolkit bugs to new owner.

Comment 10

[Frankie]

Mozilla CFM build is dead.
http://groups.google.com/groups?threadm=avkj4k%24ihs2%40ripley.netscape.com

Comment 11

[Boris Zbarsky [:bzbarsky]]

As far as I know, Internet Config exists on OSX as well.  Is this not the case?

Comment 12

[Steve Dagley]

Yes, we still need IC for Mime Type info.  Unfortunately Apple's 'replacement'
for a lot of the IC functionality, LaunchServices, pretty much had no clue about
Mime Types until Mac OS X 10.2.  Even now it isn't a suitable replacement.

Comment 13

[Simon Fraser [no longer active]]

OSX, clearing milestone.

Comment 14

[Bill McGonigle (not currently reading bugmail; please contact directly)]

Is LaunchServices good enough in Panther?

Comment 15

[Ludovic Hirlimann [:Usul]]

Isn't Internet config deprecated these days ?

Comment 16

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 17

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

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.