Closed Bug 160533 Opened 22 years ago Closed 22 years ago

.exe files are launched or saved as jpg files

Categories

(Core Graveyard :: File Handling, defect)

Product:
Core Graveyard
Component:
File Handling
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: agracebush, Assigned: law)

References

Details

(Keywords: relnote) 

steps to reproduce:
1. go to site to download mozilla stub installer 
2. click on mozilla-win32-installer.exe

expected results: dialog asking me where to save the file

actual results: dialog telling me I have chosen to save file type jpg etc. 
I cannot rename file nor launch it to install
As discussed, I had this same problem where my helper apps got modified somehow.
Bill's instructions fixed this, but since other people are experiencing it I
guess it wasn't a user error afterall!

HOW TO FIX MANUALLY:
Most likely, the server is providing this as type application/octet-stream
(correct for .exe files) but you've got a helper app registered for that
content-type that says to save it as a .jpeg file.

Go to prefs/navigator/helper applications and see if application/octet-stream is
listed there.  Delete that entry (if present) and then it should work OK. 
To record my original report: 

In the 7/30 commercial branch build whenever I try to launch an exe or save one
to disk via Netscape, it saves as a JPEG. This occured on 3 different websites
at which I needed to download .exe files and I'm not able to change the
extension back to an .exe.
I experienced the same problem Susie describes above. Her directions on how to
fix this manually worked, but a user won't know this.   I haven't changed
in prefs for Helper app handling so this does seem like a bug. I'm using a
branch build from yesterday, but I've seen this for over a week.
Do we know if this is the result of a broken daily build? Would a user upgrading
from PR1 to RTM see this? If so, then we should definitely fix this for RTM.
the workaround worked for me too, not sure why prefs got changed, have not made
any changes to them on this machine

I will try an upgrade  from PR1
Blocks: 143047
Keywords: mozilla1.0.1, nsbeta1
Whiteboard: [adt2 RTM] [ETA Needed]
Target Milestone: --- → mozilla1.0.1
The upgrade went fine, the helper application remained blank. I was able to
download exe files.  I  am using a profile that I do not change or test with.
Not sure why it picked up that helper app on 7/30 - 

cc:ing Boris Zbarsky because this issue is related to his fix for bug 120327.

Boris, would your fix help here?  Did it prevent tweaking extensions of *all* 
application/octet-stream content, or just when we figured out how to handle it 
by looking up application/octet-stream in the system settings?

My take is that once the user has a helper-app pref entry for a given content 
type, then we're compelled to try to handle that content the way they said.  
That includes changing the extension because otherwise, the system wouldn't 
launch the associated application (which it finds via the file extension).

Most likely, we could/should prevent the user from ever specifying a helper app 
entry for application/octet-stream (since that's pretty much guaranteed to be a 
mistake).

Note that you can create helper app pref entries without going to the Helper 
Applications pref panel.  The Advanced... button on the helper app dialog does 
the same thing as if you created it via Prefs.  That's probably how Susie and 
Jennifer did it.
*** Bug 160585 has been marked as a duplicate of this bug. ***
My fix prevented tweaking of extension (or rather prevented the lookup) when we
look up application/octet-stream in the system settings or in the internal
mozilla MIME data (the hardcoded "extras" stuff).  I purposefully left the user
preference case alone, since otherwise a user could not define a helper for the
application/octet-stream type...  Adding this check to application/octet-stream
as well would not be hard, but preventing the addition of such a helper apps
entry would be a better solution (less user confusion about why a helper app
entry does nothing).

Better yet would be pushing the extension-changing down past the point where the
"execute" and "save" code paths fork....
Re "The Advanced... button on the helper app dialog does 
the same thing as if you created it via Prefs.  That's probably how Susie and 
Jennifer did it."

None of us touched anything in our helper apps. That's why this was a mystery.
To answer some questions from PdM:

Q1) Do we know if this is the result of a broken daily build? 
A1) Per my conversation with Bill Law, this does not seem to be the result of a
broken daily build.

Q2) Would a user upgrading from PR1 to RTM see this?
A1) A normal user, who has not made an association for these MIME types to be
jpg, should not run into this problem.

In short, we believe this is the way we have been running for a while, and
should not be a regression from a previous release.

Let's work on a better solution for this one, on the next release.
Whiteboard: [adt2 RTM] [ETA Needed] → [adt2]
Let's get a release note on this one for MachV and 1.0.1.
No longer blocks: 143047
Keywords: relnote
*** Bug 160666 has been marked as a duplicate of this bug. ***
I have a related issue, don't think it requires a seperate bug report though. 
I'm using build 2002072104 but have had this previously.  When saving some files
types, PSD and ZIPs for example, I'm prompted to save them as EXEs.  I have no
entries in my helper apps.
QA Contact: sairuh → petersen
*** Bug 176083 has been marked as a duplicate of this bug. ***
I had the same problem, as well as a similar problem with 1.0.  Whenever I
downloaded .tar.gz files, they would be saved as .tar.gz.tar (but not
decompressed).  I think this is because in 1.0, .gz was recognized as a
Content-Encoding, which caused .tar to be recognized as the Content-Type, which
caused the extension to be changed (appened-to).

Now that I'm using 1.1, I don't have the above problem.  I think this is because
.gz is now being recognized as a Content-Type, which I believe was the subject
of somebody elses bug-report (that person thought .gz should be seen as an
encoding, so that the prior extension could determine the helper app).  While
I'm agnostic as to whether Mozilla can decompress my gz files for me (actually,
I guess that's pretty useful), I know that I *never* want Mozilla to change the
extension of files I save to disk (the person who published the file knew what
it should be named).

If Mozilla is changing extensions in order to get Windows to launch the right
helper, could it *not* do this if the user has chosen save-to-disk?  In the
latter case, I'm clearly not interested in helper applications, but I am
interested in getting the file(name) that I thought I was getting.

Thanks!
*** Bug 182309 has been marked as a duplicate of this bug. ***
Nav triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
Whiteboard: [adt2]
This was happening to me as well, on one of my Win2K machines. I don't remember
exactly when it started, I think maybe around the time I installed 1.0.1. Like
several of the other people who have commented, I did *not* try to add a helper
application; it just started happening all by itself.

I am now running 1.2.1; I deleted the application/octet-stream helper entry as
suggested, and everything appears to work correctly now.
To duplicate this bug, I can go to http://www.mozilla.org/releases/ and click on
the "talkback enabled Net Installer .exe" link.  The file is "assumed" to be a
JPG file, downloaded & then Mozilla is unable to "display" it.  I am running
Windows 2000 SP 2. 
*** Bug 186986 has been marked as a duplicate of this bug. ***
*** Bug 187778 has been marked as a duplicate of this bug. ***
I've seen this problem on version 1.2.1 and I'think that even in 1.3a.

In my paticular case the helper app associated with application/octet-stream
.jpg file was... mozilla.exe!

I haven't touched ANY settings for helper apps.

Bug still apparent in 
Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3a) Gecko/20021212

This was a clean install on a laptop running win95.

The manual fix listed in comment #1 corrected it, but the average user would be
clueless about this fix.
The average user will never have to deal with this situation again once bug 
189598 is fixed.  I'm tempted to just mark this duplicate of that one...
Depends on: 189598
OK.  So the bug that causes the bogus associations is fixed.  If you already
have such, we will _not_ remove them, since there are valid uses for setting up
a helper app entry for application/octet-stream.

So marking this fixed by bug 189598.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Verified in the 2003-01-25-08 trunk build under Windows XP.
Status: RESOLVED → VERIFIED
*** Bug 178081 has been marked as a duplicate of this bug. ***
*** Bug 188066 has been marked as a duplicate of this bug. ***
*** Bug 192348 has been marked as a duplicate of this bug. ***
*** Bug 168022 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.