|
Bugzilla – Full Text Bug Listing |
| Summary: | firefox saves files always as attachment.cgi | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 10.3 | Reporter: | Olaf Hering <ohering> |
| Component: | Firefox | Assignee: | E-mail List <bnc-team-mozilla> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Major | ||
| Priority: | P5 - None | CC: | sbrabec, vuntz, wolfgang |
| Version: | Alpha 0plus | Keywords: | should_go_upstream |
| Target Milestone: | --- | ||
| Hardware: | PowerPC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Found By: | Development | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Olaf Hering
2006-03-16 10:22:58 UTC
seems to happen with 'save link target as...' in the 'edit attachment preferences' there is a download link, which stores the file in ~/Desktop the 'save link target as...' will store it in the userdefined directory, which is not ~/Desktop in my case. Filename for save is sent by the server in the "Content-Disposition" header. If it is not present, I guess that firefox uses a heuristics. "Save link target as" is different from a direct click on the link. So did you compare the same things and which one is different and why is it not possible to use the direct click? So please describe exactly what you do and what you expect and if Firefox 1.0.x really had another behaviour. I do know that 'save bugreportattachment to local disk...' always worked. Until I upgraded to 10.1, which forced me to switch from mozilla to firefox. just go to a random bug which has an attachment. dont click on the [edit] link but on the one left from it and try to save it to disk. I tried it with a 10.0 fresh install. firefox picks the right filename. I tried it with a sles10 beta8 fresh install, firefox picks attachment.cgi. I believe this was a consequence of this upstream change: http://bugzilla.mozilla.org/show_bug.cgi?id=249759 There's a tradeoff here --- waiting for the server response means we have to delay popping up the dialog --- so I'll try to find out if this change was intended or not. Actually it was a deliberate change in https://bugzilla.mozilla.org/show_bug.cgi?id=160454 See https://bugzilla.mozilla.org/show_bug.cgi?id=299372 for the upstream version of this bug. I'm not really sure what to do here. Any update? they also broke seamonkey. It's upstream behaviour but discussion is still going on to fix it the right way. This is still happening in SLED10SP1 and 10.3. Moving to 10.3 This was a core intentional upstream change. We won't back port it, we'll just get it for FF 3. still broken in firefox 3.0 beta5. right click on first attachment in bug #387257, save link target as... I get attachment.cgi It's already fixed in upcoming FF 3.0rc1 but wasn't when beta 5 was cut. 3.0b5 is somewhat frozen for us because of the dependency to mozilla-nss and therefore crypto freeze. It doesn't even make sense to backport all this to 3.0b5 since we are talking about (currently) 451 fixed bugs in Firefox between 3.0b5 and rc1. So as soon as 11.0 is GA we will provide an online update to the latest Firefox version out at that point. it is still not working for me wit 3.0 final. see attachments in https://bugzilla.novell.com/show_bug.cgi?id=324134 right mouse click on the non-obsolete patches, all I get is attachment.cgi weird, for some reason the first two attachment were offered as attachment.cgi. But now I get always the filename. There is a timeout and when the server doesn't tell the filename within that time it doesn't wait longer but uses attachment.cgi (in that case).
pref("browser.download.saveLinkAsFilenameTimeout", 1000);
That may explain what you are seeing.
I will try 10000 and see if that helps. Olaf: can we close the bug now? Okay, assuming it's fixed since Olaf isn't here anymore. People disagreeing should feel free to reopen. |