440041 - StuffIt Expander appears in "Open With" dialog box even if StuffIt has never been installed.

Status: RESOLVED DUPLICATE of bug 489864

(Firefox :: File Handling, defect)

Description

[Joshua Mullin]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0

On a virgin OSX 10.5.3 install with firefox 3 (build noted in the Build Identifier field), downloading a .ZIP archive gives the option of "Open With" or "Download to." Among the options for "Open With" is "StuffIt Expander," a program which has never been installed on the machine.

Upon finishing the download of said .ZIP file, the OSX "Open With" dialog doesn't include StuffIt, and a spotlight search for 'stuffit' yields 0 application results.

Reproducible: Always

Steps to Reproduce:
1. Enable the "Always ask me where to save files" option in Firefox "Main" preferences tab. 
2. Attempt to download a .ZIP file from the Internet (any .ZIP will do)
3. View the "Open With" application list in the download prompt screen.
Actual Results:  
StuffIt Expander appears as an option.

Expected Results:  
Only OSX's built-in Archive program should appear (Or any other application capable of handling Application/zip mime type.

In the Applications preferences pane, StuffIt appears as the default application as well.

Comment 1

[Marcia Knous [:marcia]]

Moving this to the File Handling component. I see this too on my Leopard machine. Adding ctalbert to the list. It seems that if I check use Stuff it that it calls the Apple unzip utility. If I select "MacOS" i get an error so StuffIt is the only handler that works for me with a zip file on Leopard using "Open With."

Comment 2

[Joshua Mullin]

The behavior Marcia Knous has been observed by myself as well. Selecting StuffIt opens Apple's Unarchive tool if StuffIt is not on the system.

This bug was discovered when a client was complaining that their .zip file downloaded wouldn't open with firefox. These clients are using Firefox 2.x, so this may be a bug that has been around for a while.

Marcia Knous should also verify that the .zip files she's trying to unzip work with Apple's unarchive tool in the first place, as there is a bug I've yet to file with Apple regarding no-compression zip files not unarchiving with Archive.app.

Comment 3

[cmtalbert]

I'm Confirming this on: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a1pre) Gecko/2008070202 Minefield/3.1a1pre.

I see the same issue, and the zip file I'm using do in fact unzip properly with Apple's unarchive tool.

Comment 4

[Sierk Bornemann]

I'm confirming this on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.0.2) Gecko/2008091618 Firefox/3.0.2


Had a lot of trouble because of that issue, because i former have had installed Stuffit for real and had problems to uninstall it. I've had a lot of headaches, concerning this particulary dialog box issue of Firefox, because along time I thought, the uninstall of StuffIt has not been proper and has left back something in the system. Unless I found this filed Bug 440041. Please correct/fix this issue in one of the next Firefox releases or updates.
I find this issue a *very* annoying and confusing issue (I have spent several days of trial and research just to find out, that I can't make any change to it and that this issue is caused by Firefox itself) and completely unnessessary -- especially for users who never have been installed and used StuffIt on their system before. Especially in those latter cases, where StuffIt never has been installed, this issue gives Firefox a slight touch of "uncleanliness". Is it really inevitable, to let this issue exist any day longer?

Comment 5

[Daniel Veditz [:dveditz]]

Not a branch blocker

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

Has this been confirmed on a clean install of Firefox? A quick search shows:

http://mxr.mozilla.org/mozilla-central/search?string=stuffit

that we don't refer to StuffIt in our codebase at all. We *do* import a list of default system handlers from the OS, though, so I wonder if the reference is coming from OSX, not from us.

I see two possibilities:

1. It's coming from the OS, at which point this is INVALID
2. It's coming from old profile data, at which point we should fix that

Either way, not blocking.

Comment 7

[Joshua Mullin]

Responding to Comment #6:

I just re-installed OSX 10.5.5 (latest) and the latest firefox (3.0.3). Both are fresh installs with no preference changes. If I download a .sit archive with Firefox, I am given the option to open it with "Stuffit Expander (Default)," though StuffIt hasn't been bundled with OSX since 10.4/Tiger.

If I try to open the downloaded .sit archive with the operating system, rather than through Firefox, it tries to open with TextEdit as a last ditch effort because the OS (expectedly) doesn't know what a .sit file is.

If this is coming from the OS, the OS should behave similarly when attempting to handle this type of file. a .SIT file is a better example because OSX handles .ZIP files without a third-party app.

If you're referring to "old profile data" as profile data from FF2, then I see that as an invalid reason too, since this happens on a clean OS and FF3.0.3 install.

I'm not familiar enough with Firefox's code to go digging in a meaningful way to figure out where the "open with" dialog gets its data from, but if someone else knows where to begin, I'd go digging.

Comment 8

[Lint Hasenpfeffer]

I've been digging thru my system for the past several hours, I cannot find anything that would bind zip files to stuffit expander. However I also can't find anything in Firefox profiles that have a string of 'Stuffit'.

That much being said, FF shows 'PC ZIP Archive', which is the wording of the old 'Classic' MacOS internet config. Where is can someone shed some light on what method FF is reading this info from the system. Perhaps I can find where its populating from.

Comment 9

[Lint Hasenpfeffer]

A dump from launchservices only lists one entry for stuffit expander:

type	id:            27208
		uti:           com.allume.stuffit-archive
		description:   Stuffit archive
		flags:         imported  active  core  apple-internal  
		icon:          
		conforms to:   public.data, public.archive
		tags:          .sit, .sitx, application/x-stuffit, application/x-sit, application/stuffit

Comment 10

[Lint Hasenpfeffer]

Ok, so I am currently leaning that this bug is invalid. I have just come across MisFox : http://mac.clauss-net.de/misfox/

It not only shows the text "PC Zip Archive" but its binding to Stuffit.

So one of 2 (or both) things are happening here [I suspect]

1) If the data in this structure is deprecated but athouritztive, then this needs to be bounced to apple.

2)  If this data and its retrieval code has been superseded by a modern authoritative structure (launchservices?) then the binding code in moz should be fixed. 

So far I have not been able to get the raw OS to present this info to me. I'm leaning toward 2. But I have asked the author os MisFox to tell me where hes getting it as to see if the code is deprecated.

Comment 11

[Lint Hasenpfeffer]

Ok I think I have the root cause sussed out here. I think the hinky data is being pulled in the the calls to the old internet config. However since what I have found via launch services, and its no where to be found in LS, my guess is that the old IC code is still being used.

Of course regardless, the data IC is seeing is bad. Perhaps a change to LS as have the user not see inconsistency.

Comment 12

[Joshua Mullin]

It's been over a year since I reported this issue, and it still seems to be lingering around as new. It seems that Lint Hasenpfeffer in comments #10 and  #11 has determined the root cause. Has/Can this be verified?

Is this part of a bigger issue where LaunchServices should be completely replacing OS 9-'s Internet Config, as far as Firefox's bindings go? Has anyone found this to be happening with other types other than .ZIP?

Comment 13

[Steven Michaud [:smichaud] (Retired)]

Try a current trunk (Minefield) nightly, available at
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/

A patch for bug 489864 ("get rid of nsIInternetConfigService") landed
on the trunk on 2009-06-23.

Comment 14

[Joshua Mullin]

I just tried the Minefield revision located here:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/firefox-3.6a1pre.en-US.mac.dmg

And the problem is fixed. It now displays no application as the default for .zip, allows you to choose an application, but if you don't do so, it uses the default Archive tool in OSX to open the .zip, as expected.

I appreciate the parallel drawn to bug 489864, as it seems to have also fixed this one as well.

I'm marking this as a duplicate of bug 489864 which seems to be a broader bug with a fix already in trunk. If anyone needs more verification than my word, feel free to update accordingly. Hopefully this will see the light of day in a release soon!

Thanks.