Closed Bug 97676 Opened 23 years ago Closed 23 years ago

OS X, helper apps: unable to open either predefined or chosen app


(SeaMonkey :: UI Design, defect, P1)



(Not tracked)



(Reporter: bugzilla, Assigned: sdagley)



(Keywords: platform-parity, Whiteboard: [PDT+], [OSX+], [ETA 09.27 - see comments for details])


(2 files, 3 obsolete files)

found using 2001.08.30.05-comm bits on Mac OS X [10.0.4].

n6.x won't open either the predefined/OS helper app or a user-chosen 
helper app.

predefined helper app test:
1. go to and click on any of the download links.
2. the helper dialog that comes up will have "Open with StuffIt Expander" 
[at least on my machine].
3. click OK, then the download progress dialog appears.

results: after download is complete, Stuffit Expander doesn't launch. i 
checked the download folder, and that's there is the salted [temp] 
filename. and, if i exit the app, that salted file disappears [deleted].

user-chosen helper app test:
1. go to and select a dir which contains a filetype which wouldn't have an OS-defined helper app. for me, .bz2 files work.
2. the helper app dialog that appears will have "Open <no application 
specified>" and the "Save this file to disk" radiobutton will be selected.
3. click Choose. on my machine, i somehow cannot select the carbon 
version of Stuffit Expander [in Magpie:Applications:Utilities] --a 10.0.4 
bug? so, instead i select the classic version of the same app [in 
Perla:Applications (Mac OS 9):Internet Utilities:Aladdin folder:Stuffit 
Expander 5.5].
4. click OK, the download progress dialog appears.

results: as with predefined helper apps, Stuffit Expander doesn't launch 
after download is complete. again i checked the download folder, and 
there's a salted [temp] filename. and, again, if i exit the app, that salted file 
goes away [deleted].
[yech, IE 5.1 on mac os x has form issues --back to n6.x! :)]

nominating, OS X-only. unsure if this is a blocker, as there's a workaround by
simply selecting "save to disk"; but, alas, opening w/helper app is busted here.

should i file another bug for not being able to select the carbon version of
StuffIt Expander --or is that the "files being mistaken as unselectable folders"
bug specific to OS 10.0.x?
Not being able to pick an OS X native helper app is bug #91021 which pinkerton 
checked in the fix for yesterday.  Unfortunately while you can now select an OS X 
native app it still won't be launched.
Ahh, OK.  I was wondering if it was just me who was finding apps not launching.

I'm not sure why the reporter was finding himself unable to select Stuffit
expander (carbon); with the non-commercial 2001083005, and 10.0.4, I have no
problem choosing Stuffit Expander.
Blocks: 78106
Adding nsbranch+,nsenterprise+.  Is there a workaround?  How close are we to a
fix? Thanks!
Whiteboard: PDT
unless you count saving the file then opening the application separately as a
workaround. :)  other than that, no, there's no workaround that i know of to get
an application to actually launch from moz/n6.x...
Severity: critical → blocker
not gonna make 0.9.4 as I just got back from vacation and haven't looked at this 
Keywords: mozilla0.9.4
Priority: -- → P1
Target Milestone: --- → mozilla0.9.5
Blocks: 91871
Whiteboard: PDT → PDT [OSX+]
Dagley - Have you taken a look at this one? It's a P1 Blocker.
Whiteboard: PDT [OSX+] → PDT [OSX+],[ETA 09.24]
Keywords: nsenterprise+
marking nsenterprise- to get off the enterprise stop ship list.
Keywords: nsenterprise-
Attachment #50358 - Attachment is obsolete: true
09.24 has passed us by ... new ETA pls.
Whiteboard: PDT [OSX+],[ETA 09.24] → PDT, [OSX+], [ETA 09.24]
*** Bug 91871 has been marked as a duplicate of this bug. ***
Whiteboard: PDT, [OSX+], [ETA 09.24] → PDT, [OSX+], [ETA 09.27]
Still slogging through debugging on X but am making progress and should have 
something to check in tonight.

(Sorry, forgot to hit Commit)
Whiteboard: PDT, [OSX+], [ETA 09.27] → PDT, [OSX+], [ETA 09.27 - see comments for details]
Attachment #50755 - Attachment is obsolete: true
The last patch attached fixes the following:

- Reveal the location of the file downloaded in the Finder

- Launch the file downloaded by using the Mac OS X LaunchServices API

- Selecting an app to process the file when it finishes downloading rather than
using the helper app mapping specified in the InternetConfig (IC) prefs

It also works around the problem I didn't find a solution for which is that I
was not getting a valid helper app mapping from IC so the automatic dispatch
when the file finished downloading would fail.  This patch uses the Mac OS X
LaunchServices API to call the default handler for the file type downloaded
which may or may not be == to what the IC mapping sez it is.  You can still
override this behavior by manually selecting a helper app when downloading a
file.  Hopefully a better solution can be found for this but in the meantime I
figured a workaround was better than nothing. 
I'm not sure about all the checks against kUnresolvedCFragSymbolAddress.

In terms of checking for availability on each call, wouldn't one check, or call
to Gestalt setting a static member var be cleaner? In my patch for bug 87831,
going in tonight, I set up a method which queries the OS for such. It would be
nice to use this and set static class vars like sHaveLaunchServices all in one

Also, these calls aren't just for OS X:
 *    CarbonLib:        not available in CarbonLib 1.x
 *    Mac OS X:         in version 10.0 or later

There will come a day, possibly soon due to embedding, that we have to support
Carbon under 9. We should do what we can to make it easier to make that move
when it comes.

Yeah, checking each proc addr to see if it's non-NULL seems like a little 
overkill but the current word from Apple has been that just checking for a 
version # w/gestalt isn't sufficient.  That said, I'd be fine with simplifying 
the code to just test for the ability to init LaunchServices if you and Simon and 
Pink agree.

What do you mean by "Also, these calls aren't just for OS X:"?  LaunchServices is 
not in CarbonLib as of 1.4 and AFAIK there are no plans to make it available for 
pre-X versions of Mac OS.
> What do you mean by

Never mind that - I think I was up too late and somehow mis-read. I'll slap
myself now.
I think checking each symbol is fine; the Apple samples do it this way, so I 
guess they want to be able to add and remove calls at will. It's a very cheap 
thing to do, anyway.
pls check this in tonight - tentative PDT+, provided you get and r/sr= from
simon and conrad.
Whiteboard: PDT, [OSX+], [ETA 09.27 - see comments for details] → [PDT+], [OSX+], [ETA 09.27 - see comments for details]

+                       LSItemInfoRecord *theInfo = (LSItemInfoRecord *

This can live on the stack.

Otherwise, r/sr = sfraser, as long as you file a bug to track this:

+       // Either there's something fundamentally wrong with IC's mapping of 
helper apps
+       // under OS X or our interaction with the info we get back so for now I'm 
just going
+       // to fall back to LaunchServices and let the OS figure out how to deal 
with it
+       if (gRunningOSX)
+         return (aDocToLoad->Launch());
We're initing LaunchServices at the earliest possible time.

What's the cost of this call? The discussion in the headers says it optional and
should only be used to incur the cost at a known time. The first file
constructed wouldn't be a good time since the user might not need it immediately
if at all in the session and we're always trying to whittle down startup time.
Sounds like if we didn't make this call, the OS would initialize when needed.

Then, the little nit about making gRunningOSX a static member var beginning with "s"

The rest looks good.
Investigate the startup time issue and r=ccarlen.
Attachment #51184 - Attachment is obsolete: true
Last patch addresses comments from sfraser and ccarlen.  Note that this patch 
won't apply directly to the branch as it depends on ccarlen's patch for 87831 
which includes a static class initialization function but isn't on the branch 
yet.  A modified version to do the static flag setting in the CTOR for the OS X 
flag was checked in on the branch.

ccarlen: The pre-init of LaunchServices was removed so there should be no startup 
time impact.

sfraser: Bug 102490 was filed to track the IC helper app problem.
Closed: 23 years ago
Resolution: --- → FIXED
vrfy'd using commercial *branch* bits 2001.10.01.04 on mac os 10.0.4. tested
with both a predefined helper app.

however, when i tried manually defining a helper app from the helper app dialog
--ie, clicking Choose and selecting an app-- the app i chose was not the one
that was actually launched. eg, when i clicked a .bz2 file, i selected
[arbitrarily] BBEdit Lite. however, BBEdit Lite did not launch --instead,
QuickTime launched. mind you, there is no OS-defined helper app defined for .bz2
files [on my box], so i'm confused as to why my selection was ignored.

am i encountering another bug [bug 102490?]?

i'm going to hold off on verifying this, pending further developer feedback. :) thx!
further observations wrt my comments above:

spake with steve, and tried selecting the classic version of StuffIt Expander
[for a .zip and .bz2 file]. after it finished downloading, however, the
carbonized version of StuffIt Expander still launched. after that app finished
running, i clicked the Launch button to see if the classic StuffIt would launch.
nope, the carbonized version *still* launched.

steve mentioned he'll research this soon...
The patch to fix InitFindingAppByCreatorCode to use LaunchServices on Mac OS X 
solves the problem of not being able to automatically launch a helper app under 
OS X.  It also fixes the problem of not being able to manually specify a helper 
app in the file download dialog caused by the Launch() workaround in the original 
Resolution: FIXED → ---
The last patch got a verbal sr= from sfraser and I checked it in so we can get 
some testing in tomorrow morning's build.  Marking FIXED again
Actually marking FIXED this time
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
excellent...vrfy fixed on the branch using 2001.10.02.04 comm bits on 10.0.4.


* OS-defined helper app [.bin file]: carbonized version of StuffIt Expander
* user-defined helper app, via Choose button [.exe file]: selected the
carbonized version of BBEdit Lite, which launched.

as for the Reveal Location and Launch buttons, see my comments in bug 91871.
Keywords: vtrunk
*** Bug 102490 has been marked as a duplicate of this bug. ***
vrfy fixed on the trunk using 2001.10.03.20 comm bits on 10.0.4.


* OS-defined helper app [.bin file]: carbonized version of StuffIt Expander
* user-defined helper app, via Choose button [.exe file]: selected the
carbonized version of BBEdit 5.0, which launched.
Keywords: vtrunk
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.