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 http://mozilla.org 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 ftp://ftp.mozilla.org/pub/mozilla/nightly/ 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.

Adding nsbranch+,nsenterprise+. Is there a workaround? How close are we to a fix? Thanks!

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...

not gonna make 0.9.4 as I just got back from vacation and haven't looked at this yet

Dagley - Have you taken a look at this one? It's a P1 Blocker.

marking nsenterprise- to get off the enterprise stop ship list.

09.24 has passed us by ... new ETA pls.

*** Bug 91871 has been marked as a duplicate of this bug. ***

Still slogging through debugging on X but am making progress and should have something to check in tonight. (Sorry, forgot to hit Commit)

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 place. 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.

Conrad, 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.

Comments: + LSItemInfoRecord *theInfo = (LSItemInfoRecord * )NewPtrClear(sizeof(LSItemInfoRecord));; This can live on the stack. Otherwise, r/sr = sfraser, as long as you file a bug to track this: +#if TARGET_CARBON + // 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()); +#endif

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.

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.

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 fix.

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

excellent...vrfy fixed on the branch using 2001.10.02.04 comm bits on 10.0.4. tested: * OS-defined helper app [.bin file]: carbonized version of StuffIt Expander launched. * 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.

*** 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. tested: * OS-defined helper app [.bin file]: carbonized version of StuffIt Expander launched. * user-defined helper app, via Choose button [.exe file]: selected the carbonized version of BBEdit 5.0, which launched.