65515 - No download possible in certain situations

Status: VERIFIED DUPLICATE of bug 105151

(Core Graveyard :: File Handling, defect, P3)

Description

[Andreas Pleschutznig]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20010115
BuildID:    2001011504

I have the IMP webmail package installed and every time when I try to download
an attachment, the download window comes up telling me that I have an unknown
octet stream, and asks for cancel or download or open. When I click on download
all that happens is that the download screen comes back. The URL for the IMP
package is:  http://horde.org/imp This does work in all Versions 4.x and in all
IE versions

Reproducible: Always
Steps to Reproduce:
1.Try to download an attachment
2 [details] [diff] [review].
3.

Expected Results:  Open the file chooser window and start the download

Comment 1

[Keyser Sose]

Reporter do you have a testcase/testlogin we can use? None of us have the
software you are refering too. Thanks.

Comment 2

[Andreas Pleschutznig]

OK, I created a testaccount for everyone to test it.

Connect to: https://mail.ple.org/horde/imp
Login with USer: 'testuser' and passwd 'testuser' There should be at least one
e-mail with an attachment in there. Click on the e-mail and on the view message
screen hit the floppy icon close to the attachment to download the attachment.

Thanks 

Comment 3

[Keyser Sose]

WORKSFORME
Platform: PC
OS: Linux 2.2.16
Mozilla Build: 2001011608


Reporter: I am going to try on Winblows tommorow but in the mean time try using
a new profile and see if that fixes the probem.

Comment 4

[Andreas Pleschutznig]

I just tried to change to a new profile as requested. While changing to a new
profile helps with another bug, it does not help with this one. The behaviour is
still the same.

Comment 5

[Keyser Sose]

Confirmed
Platform: PC
OS: Windows 98
Mozilla Build: 2001011704


This seems to be a Windows only problem. Linux has no problems with it. Marking NEW.

Comment 6

[Asa Dotzler [:asa]]

over to xpapps.

Comment 7

[Asa Dotzler [:asa]]

reassign: mscott.  cc: law

Comment 8

[Scott MacGregor]

Attaching the fix now. If we can't find a mime entry for the attachment in the
windows registry then create a new mime entry instead of returning failure. This
was causing the ucth dialog to show up by mistake. Linux already had code to do
this. I forgot to add it to the windows specific code too. This patch also
contains separate fixes for 57364 and 65872. 

Comment 9

[Scott MacGregor]

Attachment: fix for this and some other bugs.

Comment 10

[Scott MacGregor]

I checked this fix in the other day. 

Comment 11

[sairuh (rarely reading bugmail)]

hrm, unless i got a verif build that didn't get mscott's checkin [2001.01.23.09,
commercial, winNT], i'm unable to save the attachment. followed Andreas'
instructions in the 2001-01-16 21:40 comments, here's what i saw:

- click the floppy icon. result: got the Unknown File Type [UFT] dialog.
- click the Save File button in the UFT dialog. result: button indents, but
nothing else happens, ie, the Save File dialog [file picker] doesn't show up.

reopening.

Comment 12

[sairuh (rarely reading bugmail)]

still a problem using 2001.01.25.2001 commercial verif bits on winNT...

Comment 13

[Scott MacGregor]

The remaining problem is with our invocation of the windows file picker. For
some reason it is just failing in this particular circumstance. I tracked it
down to:

result = ::GetSaveFileName(&ofn); on line 164 of nsFilePicker.cpp just fails. 

over to the owner of this code.

Comment 14

[sairuh (rarely reading bugmail)]

ugh, i was looking at the wrong build there [sorry!]. however, i still cannot
save the attachment when [really] using the 2001.01.25.11 winNT bits. result is
a bit different --instead of getting the UFT dialog, i do get the helper
app/downloading dialog. but after i click on OK [Save to disk selected], no file
picker appears.

Comment 15

[Viswanath Ramachandran]

nav triage team: looks like bill law shd get this. reassigning to him. 

Comment 16

[Paul Chen]

nav triage team:

Moving nsbeta1+ from status whiteboard to keyword, setting target milestone to 
mozilla0.9.1

Comment 17

[Bill Law]

I suspect this might be related to bug 78943.

Comment 18

[Bill Law]

Removed +, probably not a beta stopper.  Resetting target milestone, too.

Comment 19

[Paul Chen]

nav triage team:

Pushing out to mozilla0.9.3

Comment 20

[Paul Chen]

nav triage team:

Not a mozilla0.9.3 stopper, marking mozilla1.0

Comment 21

[sairuh (rarely reading bugmail)]

spam: over to File Handling.

Comment 22

[sairuh (rarely reading bugmail)]

dupping per triage mtg.

*** This bug has been marked as a duplicate of 105151 ***

Comment 23

[sairuh (rarely reading bugmail)]

mass verification of duplicate bugs: to find all bugspam pertaining to this, set
your search string to "DuplicateBugsBelongInZahadum".

if you think this particular bug is *not* a duplicate, please provide a
compelling reason, as well as check a recent *trunk* build (on the appropriate
platform[s]), before reopening.