115207 - filename in file picker should not include extension

Status: NEW

(Firefox :: File Handling, defect)

Description

[sairuh (rarely reading bugmail)]

when saving a file [via Save Link or Save Image], the filename in file picker
should not  include extension, since the filtering should provide the extension.
at least it should on win32 and mac --not sure about what's expected on
linux/unix [although the correct filter is chosen on my linux box].

recipe A:

1. go to http://cnn.com/
2. bring up the context menu over the ad banner near the top-right of the page
--it's an image file which lacks an extension, it's just called "aol"
3. select Save Image and look at the resulting file picker.

results A: on all platforms, the file picker correctly chose the GIF filter.
however, the filename in the picker is "aol.gif" rather than just "aol".

here's another illustration of where this might actually confuse the user:

recipe B:

1. go to http://mozilla.org/
2. bring up the context menu for the "At A Glance" link on the left side of the
page.
3. select Save Link. the resulting file picker says "At A Glance.html" in the
filename field.
4. change the filter choice to "Text File", then save the file.

results B: the filename in the picker remains as "At A Glance.html", and it's
also saved as "At A Glance.html".

expected: shouldn't the file have been saved as "At A Glance.txt"? then again i
don't know how much this particular case might be affected by bug 42441...

Comment 1

[sairuh (rarely reading bugmail)]

could this bug and bug 115210 be dependent on bug 31519, perchance?

Comment 2

[Boris Zbarsky [:bzbarsky]]

On linux, we had better save under the _exact_ name in the box, without sneakily
appending anything to it.  Same thing on the mac.  If the user chooses to not
have a ".gif" extension on a gif file, then we should allow him to do that on
those two platforms.  This means that the original name we display on linux
should include the extension.  On the mac we could leave the extension off, and
save the file without the extension (just make sure we set the type field
correctly).

On windows, it seems to me we should follow the system "show extensions"
preference, no?

Comment 3

[Andrew Hagen]

I think sairuh is right about the interdependencies of the three bugs (this one
and the two sairuh mentioned.) 

The Windows "show extensions" setting won't help to resolve this bug, because
there is no icon accompanying the file being downloaded. In Windows explorer, a
TXT file gets an icon that a Windows user learns to eventually recognize. In the
Mozilla save dialog, there won't be any icon.

The full filename should be provided on all platforms. Otherwise the user will
be confused. This bug should be marked invalid or wontfix.

Comment 4

[Dan Tobias]

I agree with those who say that the full filename should be shown, extension and
all... I hate software that sneakily adds extensions without my knowledge or
consent, or that treats me like a moron by trying to hide "tech stuff" like file
extensions from me.

Comment 5

[Peter Trudelle]

ADT triage team needs info: Does the correct extension now get added in this
case recipe B)? Is there a separate bug on that?

Comment 6

[Boris Zbarsky [:bzbarsky]]

See related bug 120313

Comment 7

[sairuh (rarely reading bugmail)]

tested using 2002.02.25.0x comm bits on linux rh7.2 and win2k --unable to test
on mac due to bug 107521.

with recipe B:

issue #1: when i select "text file" from the file picker, the extension remains
as .html. and after i click "save" the page is saved as an html file [mozorg.html].

issue #2: however, if i explicitly change the filename in the picker to have an
.txt extension [still have "text file" chosen as the save option],  the file is
saved as "mozorg.txt", but the file itself contains html source.

i'm kind of confused now --shouldn't the html source be stripped out? i re-read
bug 42441, where saving as text was implemented, and ran a couple of tests: if i
save the page via the File > Save Page top-level menu or accel+S, then select
the "text file" option, the page is indeed saved as text. however, this doesn't
seem to work when i save via the context menu item "Save Link As" and select the
"text file" option...

should i file another bug for issue #2 [certainly don't want to morph this one]?
or, am i encountering the end result of bug 117269 and/or bug 120313?

Comment 8

[Boris Zbarsky [:bzbarsky]]

No, issue #2 is a separate bug.  For "Save Link As" we're completely ignoring
the user-selected type in the picker... we should either not offer text/plain as
a type there or we should do the right thing for it.  Please cc me on the new bug?

Comment 9

[sairuh (rarely reading bugmail)]

filed bug 127912 for the saving as text via "save as link" issue.

Comment 10

[Peter Trudelle]

ADT triage team is still somewhat confused over what cases are not handled by
bug 127912. Sarah, could you please explain in person?

Comment 11

[Boris Zbarsky [:bzbarsky]]

*** Bug 128614 has been marked as a duplicate of this bug. ***

Comment 12

[Peter Trudelle]

nsbeta1+ per Nav triage team

Comment 13

[Peter Trudelle]

nsbeta1- per Nav triage team

Comment 14

[Gingerbread Man]

Is this... like, halfway fixed now?

I tested in the current nightly on Windows 7. "Hide extensions for known file types" is enabled.
* Save Page As on this page shows the file extension. This is appropriate, because I don't have CGI associated with anything.
* Save Link As on the bug number link at the top of this page hides the file extension. This is not appropriate, for the same reason as above.
* Save Image As properly hides the file extension for known file types.
* Save Image As makes a bit of mess of things when images are served without an appropriate file extension. For example, thumbnails on Bing image search show as thumbnail.aspx in the file picker, and get saved as thumbnail.aspx.jpg. Given that extensions for known file types are hidden, Windows Explorer shows the resulting image file as thumbnail.aspx, which is confusing.

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:Gijs, could you have a look please?
For more information, please visit auto_nag documentation.