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

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P1)

Description

[sairuh (rarely reading bugmail)]

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

Comment 1

[sairuh (rarely reading bugmail)]

[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?

Comment 2

[Steve Dagley]

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.

Comment 3

[Steve K]

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.

Comment 4

[grega]

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

Comment 5

[sairuh (rarely reading bugmail)]

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

Comment 6

[Steve Dagley]

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

Comment 7

[Jaime Rodriguez, Jr.]

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

Comment 8

[Steve Dagley]

Attachment: Ignore this, just storing current work here so I can patch another tree

Comment 9

[grega]

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

Comment 10

[Steve Dagley]

Attachment: Still work in progress but now Reveal works

Comment 11

[Jaime Rodriguez, Jr.]

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

Comment 12

[Steve Dagley]

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

Comment 13

[Steve Dagley]

Still slogging through debugging on X but am making progress and should have 
something to check in tonight.


(Sorry, forgot to hit Commit)

Comment 14

[Steve Dagley]

Attachment: This patch is ready for review - see comment following checkin for caveats

Comment 15

[Steve Dagley]

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. 

Comment 16

[Conrad Carlen (not reading bugmail)]

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.

Comment 17

[Steve Dagley]

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.

Comment 18

[Conrad Carlen (not reading bugmail)]

> What do you mean by

Never mind that - I think I was up too late and somehow mis-read. I'll slap
myself now.

Comment 19

[Simon Fraser [no longer active]]

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.

Comment 20

[Jaime Rodriguez, Jr.]

pls check this in tonight - tentative PDT+, provided you get and r/sr= from
simon and conrad.

Comment 21

[Simon Fraser [no longer active]]

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

Comment 22

[Conrad Carlen (not reading bugmail)]

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.

Comment 23

[Conrad Carlen (not reading bugmail)]

Investigate the startup time issue and r=ccarlen.

Comment 24

[Steve Dagley]

Attachment: Patch as applied to the Mozilla trunk

Comment 25

[Steve Dagley]

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.

Comment 26

[sairuh (rarely reading bugmail)]

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!

Comment 27

[sairuh (rarely reading bugmail)]

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

Comment 28

[Steve Dagley]

Attachment: Fix InitFindingAppByCreatorCode to use LaunchServices on Mac OS X

Comment 29

[Steve Dagley]

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.

Comment 30

[Steve Dagley]

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

Comment 31

[Steve Dagley]

Actually marking FIXED this time

Comment 32

[sairuh (rarely reading bugmail)]

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.

Comment 33

[Steve Dagley]

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

Comment 34

[sairuh (rarely reading bugmail)]

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.