Open Bug 68515 Opened 24 years ago Updated 2 years ago

Use Internet Config as base for Helper Apps pref UI

Categories

(Firefox :: File Handling, defect, P3)

PowerPC
macOS
defect

Tracking

()

People

(Reporter: lordpixel, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: helpwanted, Whiteboard: [se-radar])

Once bug 68514 and bug 68513 are fixed, we need some user interface to allow the 
user to change these settings from within Mozilla.

This needs to be integrated with Internet Config such that when the user makes 
changes in Mozilla, the system wide Internet Config settings are also changed, 
otherwise the user will become extremely confused! :) 

The basics of the UI should be to pick up the correct icon and descriptions from 
internet config and display them. 

However, since Internet Config only has the concepts of "Save to disk" and "Open 
With Application" we would need to extend this to say "Handle internally in 
browser" and "Handle With Plugin". This means Navigator must store 2 of the 
possiibilities internally, then defer to Internet Config for the other two 
possibilities. Perhaps not the easiest thing for the backend, but this is a bug 
on what the UI should do.

See IE5 on Mac OS for an example.

Whether we want preferences for protocols (confusingly known as Helper Apps in 
the Internet control panel) and for filename extensions and mime types (Moz's 
idea of what a helper application is, known as "File Mapping" in the internet 
control panel) I don't know. 2 seperate preference panels might be too confuding
Blocks: 5271
Depends on: 68513, 68514
Summary: Use Internet Config as base for Helper Apps pref UI → Use Internet Config as base for Helper Apps pref UI
Blocks: 5721
No longer blocks: 5271
->pchen?
Assignee: matt → pchen
QA Contact: sairuh → shrir
Erk. Having mozilla mess with IC settings is a world of hurt. You should have 
just a single UI for a given set of data, unless your UI makes it *really* clear 
that you are going to nuke the system-wide IC settings with the changes you are 
making (Mozilla bugs and all).

I'd strongly recommend that we just have buttons to fire up the Internet Control 
Panel to show the appropriate data for editing.
Simon: what a wonderful idea!

For some reason I'd been assuming "you" (meaning the nebulous Moz minions en 
masse) wanted Navigator to have its own UI for this. But frankly I've no idea why 
I assumed that and simply opening the Internet control panel on the right page is 
so much easier and IMO better...
This is what iCab does -- just providing a button linking to the `Helper Apps' 
panel in the Internet control panel. However, there are a number of drawbacks 
to this approach.
*   Mozilla has a concept of opening a particular filetype in Mozilla itself,
    but the Internet control panel does not -- short of specifying Mozilla
    itself as the helper app, I guess.
*   In Mozilla you can open particular filetypes with plugins, but you can't
    control plugins in the Internet control panel. This would mean that, like
    iCab, we would have to have a separate panel anyway just for plugins. So we
    wouldn't really gain any simplicity.
*   The Internet control panel includes protocols along with MIME types. While
    bug 11459 remains unimplemented, we would be obeying some of the prefs in
    this panel and completely ignoring others, which would be confusing.
*   Making the user use two different windows to set up a single Web browser
    (if that was all they were using) would be unfortunate.

> unless your UI makes it *really* clear that you are going to nuke the
> system-wide IC settings with the changes you are making

I've been thinking about this problem for quite a while. I think there would be 
a button or checkbox at the bottom of each panel (in a block similar in 
appearance to the Header block for the panel), which when clicked would 
synchronize the Mozilla settings and the Internet control panel settings. 
However I still haven't worked out the details of which direction the 
synchronization would flow in, or whether the synchronization would be live (as 
it is in Internet Explorer).
> *   Mozilla has a concept of opening a particular filetype in Mozilla itself,
> but the Internet control panel does not -- short of specifying Mozilla
> itself as the helper app, I guess.
> *   In Mozilla you can open particular filetypes with plugins, but you can't
> control plugins in the Internet control panel. This would mean that, like
> iCab, we would have to have a separate panel anyway just for plugins. So we
> wouldn't really gain any simplicity.

How about using Internet Config as the base, and then letting the user override
Internet Config with preferences specifying certain MIME types that should be
viewed with plug-ins or with Mozilla internal handling. The Mozilla prefs would
override Internet Config choices (e.g. for text/html or image/png) but Mozilla
would use the Internet Config choices for any MIME types not specified in prefs. 

> *   The Internet control panel includes protocols along with MIME types. While
> bug 11459 remains unimplemented, we would be obeying some of the prefs in
> this panel and completely ignoring others, which would be confusing.

But ignoring *all* the preferences in the Internet control panel is confusing, too.

> *   Making the user use two different windows to set up a single Web browser
> (if that was all they were using) would be unfortunate.
> 

Making the user use two different windows to set up multiple Web browsers is
also inconvenient, as is ignoring the helper app settings the user has set in
the Internet control panel. 
Well, solving half of the first problem is quite easy:

"Open WAV files using"

(*) Mozilla (built in)

( ) Plugin	[Quicktime Plugin |v]

( ) Setting from Internet Conrol Panel: |Sound Machine|

[Open Internet Control Panel]

Of course, Mozilla then needs a scrollable list of "file types", so its not as 
simple as having one big "Open Internet Control Panel" button. I missed this 
facet before.

I quite like this model, where we supplement Internet Config but defer to it as 
soon as the user chooses to use it for a type. Avoids need to synchronize, and 
makes it *really* explict to the user when they're configuring Internet Config 
(because they have to open it to do so).

We should decide on the UI, then file bugs on the back end for things that don't 
work right. Designing UI around back end bugs is highly undesirable, and we don't 
have the resources to waste time making a point solution to work around backend 
bugs for a single release then undoing it for the "real right UI" in the next 
release. (not to mention changing it an extra time would confuse people).
ooh that looks good. it'd solve the same problem w/ windows too :-).

If a user wants to register an object/protocol w/ Internet Config to use 
Mozilla, I presume we leave that to them to do on their own in Internet Config?

(*) Mozilla (built in)

( ) Plugin      [Quicktime Plugin |v]

( ) Setting from Internet Conrol Panel
     /Sound Machine/
marking p3 and future
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → Future
Isn't this one of the *most requested* features, to have a fully-fledged helper 
app UI? Why is it being pushed off again?
Component: Preferences → File Handling
QA Contact: shrir → sairuh
bill wouldn't this be part of your current helper app work [except that it's
mac-oriented]? ie, either bug 106074 and/or bug 106077?
Keywords: helpwanted
->default owner
Assignee: pchen → law
Status: ASSIGNED → NEW
Target Milestone: Future → ---
restoring target milestone
Target Milestone: --- → Future
QA Contact: sairuh → petersen
Whiteboard: [se-radar]
Mozilla CFM build is dead; should this bug go with it?
IC still exists on OSX, no?
OS: Mac System 8.5 → MacOS X
yes, but IC on OS X is (alas) a lot more stripped down; the helper applications
(and protocol handlers) are no longer displayed.
Assignee: law → nobody
QA Contact: chrispetersen → file-handling
Product: Core → Firefox
Target Milestone: Future → ---
Version: Trunk → unspecified
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.