Closed Bug 43585 Opened 24 years ago Closed 24 years ago

[FEATURE] Add default helper application support on the Mac using Internet Config

Categories

(Core Graveyard :: File Handling, defect, P1)

PowerPC
Mac System 9.x
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mscott, Assigned: paulkchen)

References

(Blocks 1 open bug)

Details

(Whiteboard: [nsbeta2-][nsbeta3+])

Branching this off from the parent Bug #38374 --> implementing helper
application support.

Gordon didn't have a chance to get the helper app stuff working on the Mac using
internet config before he had to leave today. So we didn't get this in by the
midnight deadline.  He's also worried that we may have to move some of the
mozilla seamonkey code that currently uses internet config around so that he can
get to it cleanly from the uriloader.

I'm not sure how this works from here. Does it get feature exception status? Or
is this cut for 6.0?

Seth Spitzer and I implemented user override support on the Mac so the user will
be able to go through theprefs UI to add mime type and helper application
information and that will work. But we won't be going through internet config
for this information as we didn't know how to do that.
setting priority and keyword stuff.
Severity: normal → critical
Keywords: nsbeta2
Priority: P3 → P1
Gordon and I think we have a pretty easy solution for exposing mozilla's IC
instance to the uriloader by adding a new nsIInternetConfigService.idl file.
Davidm, already has a C++ class that gets the global instance. We just need to
wrap that class with an interface so other components can access it.

Then this service needs to register itself with a progid.

the exthandler code can then invoke this service dynamically, get at the IC
instance and start fetching the mime type stuff we need.
Adding exception feature to status whiteboard
Whiteboard: Exception feature
is there a eta for this being checked in yet? QA would like to know so that we
can test this.
Adding myself to cc: list.
Putting on [nsbeta2+] radar for beta2 fix. 
Whiteboard: Exception feature → [nsbeta2+] Exception feature
*** Bug 13183 has been marked as a duplicate of this bug. ***
Doron, you're listed on the mozilla testers page as being Win98-specific. 

If the page is in fact correct, could you please QA assign this bug to any 
Macintosh-happy tester? (I volunteer if necessary.)

Thanks!
OS: Windows NT → Mac System 9.0
[Copying blockers from bug 13183, which was marked as a duplicate of this one.]
Blocks: 4252, 5721
Doh, thanks, Matthew, totally forgot about that.
Mac help, pchen.
Assignee: gordon → pchen
picking up the ball...
Status: NEW → ASSIGNED
Why doesn't Gordon own this anymore?
Target Milestone: --- → M17
I don't know....that's a good question. Looks like mcafee changed it. Hey Chris,
do you know why moved this from Gordon to Don's group?
my error, back to gordon
Assignee: pchen → gordon
Status: ASSIGNED → NEW
Well, it looks like Gordon is on vacation, so if this is gonna make beta 2, Paul
will have to do it.
Assignee: gordon → pchen
*** Bug 5721 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Whiteboard: [nsbeta2+] Exception feature → [nsbeta2+] Exception feature ETA 7/21
Whiteboard: [nsbeta2+] Exception feature ETA 7/21 → [nsbeta2+] Exception feature ETA 7/25
add self to cc
Why has Bug 5721 been marked a duplicate of this bug? Shouldn't it be the other 

way around? Adding default helper support is a subset of adding Internet Config 

support.



- Adam

I don't think Paul's had a chance to work on this yet and Gordon didn't have a
chance to start it before it got re-assigned, I'm thinking we should cut this
for beta2 and reschedule for beta3. 
I'm still thinking we should cut this for beta2. The changes necessary aren't 
necessarily trivial and it would add more risk than we probably want this late 
in the beta2 game. Can we just reschedule this for beta3?
I'm not seeing any objections to my postings about removing this from the beta2
lit. So I'm going to go ahead and do so now. 
Keywords: correctness, nsbeta3
Whiteboard: [nsbeta2+] Exception feature ETA 7/25
Recc. [nsbeta2-][nsbeta3+] per above comments.
Currently, I'm busy fixing 46531 - Crash closing a window while it's loading, so 
until that's done, there won't be any progress on this one. I second mscott's 
motion to downgrade from nsbeta2+
beta2 minus per request
Whiteboard: [nsbeta2-]
Marking this [nsbeta3+].  Also marking s blocker for bug 35915.
Blocks: 35915
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3+]
Adding sfraser to cc list
Nomimate for nsmac2, especially since bug 5721 was nsmac2 an was demoted in
favour of fixing this simpler bug!
I'm starting to get nervous that this isn't going to make it for beta3. It's a
big job and it sounds like no one has started working on it yet. I'd hate for
hit to slide like it did for beta2. Can anyone re-assure me?

This should be at the very top of the beta3 bugs we tackle IMHO. We don't want
to be waiting until the last minute to land it.

Sorry if I sound whiny...I'm just worried 'cause I haven't seen any activity on
this bug yet.

nsmac1 this puppy
Almost there, once mscott explains to me how the helper app backend works, it
will be fine. Should be in no later than tomorrow, Friday, 9/1.

Right now, for example, if I try to download mozilla-win32.zip, InternetConfig
launches 4.x to download the file because that's what I have registered to
handle "http" URL's. Obviously, that's not the right thing to do, but it shows
we can call IC no problem.
ok, this will get checked in Tuesday, 9/5, once I get reviews from mscott and
one mac person (for mac stuff I had to fix along the way).
Couldn't find mscott, but smfr code reviewed all my changes. Problem is he has
Mac build changes which affect me, so I need to pull, fix stuff, and rebuild.
Hopefully, I can get this checked in tonight.
=( sorry you couldn't find me. I've been at my desk all day but must have been
in meetings or something. I'd be happy to review any patches you have in
addition to simon's stuff if you'd like an extra set of eyes. Feel free to send
diffs to me...o.t. simon's r=sfraser is good enough for me.
Blocks: 50326
ok, I've just checked in, should see some cool helper app lovin' in tomorrow's
build on the Mac
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Grrr, so I have found out that all the work I did only helps http links, for
"Save Link As..." and ftp downloads, there are different code paths taken.
Hey Paul, don't worry about that problem. Bill and I already have stuff to track it.

Helper apps are only invoked on link click urls. 
as elig@netscape.com suggested, making Asa qa contact to verify this Mac bug.
QA Contact: doronr → asa
Paul Chen, how should I verify this bug?
If no one else comes up with a formal test plan:

Open the Internet control panel
Do Edit->User Mode and switch to advanced.
Advanced Tab

Helper Applications Settings -> Observe how this maps protocols to applications
e.g. on my system nntp maps to Netscape Communicator.

On the File Mappings Settings observe how this tab maps filename extensions to 
mimetype and to 2 different applications. An application to own the file 
(creator/type) and an application which should process the file.

Often only one of the two will be set, i.e. the processor will be set to "Save To 
Disk" the idea is the processor should get a shot at processing the file (e.g. to 
ecompress it) before the file is mapped to the creator and type of the specified 
application.

I suspect Paul's work only applies to the Help Applications settings. 

If this is the case you can verify this bug by verifying that an nntp URL typed 
into the location bar launches the application that the Internet control panel 
says that it will. (Also repeat for 1/2 dozen protocols of your choice, paying 
special attention to ones that mozilla implements http/nntp/ftp/finger v.s. ones 
that it does not gopher, telnet)

Then see what happens if you make an HTML page which has <a href="gopher: "> etc 
links in it. Try running this both from a local disk as well as a server (i.e. in 
one case there may be a mime type, in the other case there will only be the 
protocol name)

This will probably point out a few bugs:

1/ Should mozilla register itself as the default handler for http etc?
2/ Are arbitrary protocols working in the location bar?
3/ Are they working from a href links in documents. On disk? On the server?
4/ Should mozilla respect the settings for protocols it does implement? e.g. the 
http:// protocol setting. i.e. if this says netscape 4, should it launch netscape 
4 to view http delivered documents (almost certainly not, but can it similarly 
ride roughshod over the user's ftp:// setting?)

5/ Test on other platforms. Post to the newsgroups. Find or file more bugs to 
cover all the things that don't work at present.

6/ In protocols that have mime types, protocols and filename extentsions, which 
takes precedence. What's the algorithm for determining this?


7/ Do Edit->Preferences. Look at the help application tab. Why is it blank? Where 
are the names and icons of the helper applications?

Hmmm, so what I've demonstrated is I don't have a clue how this is supposed to 
work. Casual testing indicates that it doesn't work when typing into the location 
bar.

I imagine great minds have already done considerably more thinking about this 
than I have. Lets see a few more comments, then I'll help file appropriate bugs.
Ummm, lordpixel isn't entirely correct. As it turns out, as I commented on 9/8,
fixing nsOSHelperAppService.cpp only added helper app support for http
downloads, near as I can tell. So, sorry, no external protocol support, no ftp
and "Save Link As..." helper app support either. In testing this bug, I did
stuff like download mozilla daily builds from the website (NOT through ftp) and
downloaded mp3's from mp3.com (may I suggest Lagoona if you don't mind "trance"
music). Remember as long as the download is via http AND you have a mapping for
the mime type of the file and/or the file extension in Internet Config, it
should at least have the correct file type and creator and will launch the
helper app if you have specified so -- opening the Internet control panel,
making sure you're in advanced mode, select the "Advanced" tab, look at the File
Mapping prefs, double click an entry, click "Show Advanced Options", if "Handle
by:" is set to "Processing with Application" then that helper app should launch
and "open" that file. Hope this helps.
OK, so in Mac terminology this is more of a fix for file mapping support than 
"Help Application" support, but of course, its consistant with the way that 
Communicator used the term helper application.

So do we have bugs open for all of the other features in this list or should I 
file some. I'm thinking especially the fact that the preferences panel for helper 
apps is blank. Not sure you can ship without that...
Product: Browser → Seamonkey
OS: Mac System 9.x
Component: General → File Handling
Product: SeaMonkey → Core
QA Contact: asa → file-handling
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.