1208798 - Alt-click ignores server-provided filename with non-default "browser.altClickSave" value

Status: NEW

(Firefox :: File Handling, defect, P5)

Description

[xyzdragon]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150630154324

Steps to reproduce:

I have a link to an image.php site which serves me imagename.jpg.
Normally I would use RMB->save link as: File Dialog opens with default name: imagename.jpg
In order to circumvent the obnoxious file dialog I set browser.altClickSave to true, so now I do:
alt+LMB on the link to image.php



Actual results:

The images was saved as a file named 'image.php'


Expected results:

The images should have been saved as 'imagename.jpg'.

Comment 1

[xyzdragon]

For example a link to a file image.php containing this script:

<?php
    header('Content-Type: image/png');
    header('Content-Disposition: inline; filename="test.png"');
    $im = @ImageCreateFromPNG('test.png');
    imagepng($im);
    imagedestroy($im);
?>

and an aritrary test.png image in the same folder where image.php is located, will result in the described behavior.
With "Save Link As" it will be saved as 'test.png' with alt+click as 'image.php.jpg'

Comment 2

[Gingerbread Man]

(In reply to xyzdragon from comment #0)
> I have a link to an image.php site which serves me imagename.jpg.

Please provide a link to such a page.

Can you reproduce the issue in the latest Nightly in a brand new profile?
https://support.mozilla.org/kb/profile-manager-create-and-remove-firefox-profiles
https://nightly.mozilla.org

Comment 3

[xyzdragon]

The nightly build is even worse, it seems to completely ignore the browser.altClickSave setting.
But I tried it with Firefox 41 after deleting/renaming my profile folder and the problem is the same there.

Here is a link to a test page which provides a link to the image.php described above:
http://xyzdragon.bplaced.net/

Comment 4

[Gingerbread Man]

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:44.0) Gecko/20100101 Firefox/44.0
20150927030300

Thank you for the update.

(In reply to xyzdragon from comment #3)
> The nightly build is even worse, it seems to completely ignore the
> browser.altClickSave setting.

Bug 1109146.

Comment 6

[Gingerbread Man]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
20180408100251

Paolo, this has been sitting around for 3 years and a duplicate was just filed. I'd appreciate it if you could get it some attention.

Comment 7

[:Paolo Amadini]

Thanks for finding the duplicate. I took a look at the code and I think this would not be easy to fix because of how this hidden feature is implemented, since the code path does not take server-provided information into account.

In fact, this about:config preference adds an extra download code path that may not even make sense in all scenarios. I don't think we should necessarily remove this feature outright, but we shouldn't spend time on maintaining it either, and we may remove it at any time if it makes code maintenance simpler.

If an experienced contributor comes up with a patch to support the basic use case and also makes the code simpler by going through a different path, removing the support in openUILinkIn, we might consider it. But this isn't a good first bug for a new contributor.

Comment 8

[Kirill Müller]

I'd like to mention that Chromium's download manager was, for a long time, the reason for me to stay with that browser. It just puts it where I want all downloaded files to be, no questions asked. If I want, I can open the file with one click. I can schedule opening a large file after download, with just the same click.

I did some research, and there just doesn't seem to be a viable alternative in Firefox. Download managers want way too many permissions. Alt+Click was the closest I could find, and I'm happy to use it but then it doesn't work in some edge cases. (The other case is where the click triggers some JavaScript that initiates a download; Alt+Click doesn't work either, but these cases are rare, fortunately.)

Maybe Alt could just act as a modifier at the time when the "Save as/open with" dialog is shown? If the browser window/tab still has focus when download starts, and Alt is pressed, bypass all dialogs and just save to `~/Downloads`? I'm not deeply familiar with the codebase, but I suspect this logic would be easy to implement and to maintain, and the total number of code paths would be reduced. Even better, if there was a new option that implements Chromium's behavior (never show dialogs), I'd never have to think about pressing Alt, but I'm pretty sure I'm not the first to request this feature.

Some evidence that other users feel similarly:

- https://superuser.com/q/848756/99136

- https://superuser.com/q/126903/99136

- https://superuser.com/q/1024213/99136