418476 - File type not added to file if no extension entered in save dialog

Status: NEW

(Core :: Widget: Cocoa, defect, P4)

Description

[Nicolas Mandil (:NicolasWeb)]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; fr; rv:1.9b3) Gecko/2008020511 Firefox/3.0b3
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; fr; rv:1.9b3) Gecko/2008020511 Firefox/3.0b3

If you download a file by changing it name in the save as dialog and canceling it extension (ex. .jpg) the file has no file type.

Reproducible: Always

Steps to Reproduce:
1.Try to "save as" an image of a web page without the .jpg extension
2.
3.
Actual Results:  
a non-typed file is donwloaded

Expected Results:  
Keep the file without the extension but mime-type it (here, as a jpg).

Maybe this is not a mac specific bug.

Comment 1

[Nicolas Mandil (:NicolasWeb)]

Notice that in the save dialog, Fx know the file type yet (see initial extension and dropdownlist control)

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

--> Core::File Handling where this might get more attention :)

Comment 3

[Dave Webber]

The cause of the issue here, as I see it, is that the whole default filename is initially selected, when the part preceding the extension should be initially selected instead. If the pre-.ext part of the default filename was initially selected instead, then users wouldn't tend to accidentally replace the suffix when they type a new filename. This would bring the Save As dialogue closer to parity with Safari, and more in line with the expected user interface in Mac OS X in general. (The issue of the missing "Hide extension" checkbox would remain, but that's outside this topic; perhaps I'll file a bug on that later.)

But the way, perhaps cuts-os or cuts-cruft would make more sense here than cuts-control?

Comment 4

[Nicolas Mandil (:NicolasWeb)]

(In reply to comment #3)
> If the pre-.ext part of the default filename was initially
> selected instead

Maybe this is a way to make it works, but to solve it well, Fx should :
- have a "Hide Extension" checkbox
- when the user edit the .ext, Fx should check the "Hide Extension" checkbox (parity with OSX apps)

With this, we are sure that the filetype is well written in every case.

> (The issue of the missing "Hide extension" checkbox would remain,
> but that's outside this topic; perhaps I'll file a bug on that later.)
Right, do it (with the auto-check if the user edit the .ext)

> perhaps cuts-os or cuts-cruft would make more sense here than
> cuts-control?
I agree that cuts-os make sens here, but I think that beginners just understand that "they can't open a file they've saved", so I think that cuts-control make sens too, no ?

Comment 5

[Siarhei]

I have the same problem. Usually I download Firefox or Thunderbird from mozilla.com and change a file name to contain a language code of downloaded installer. There is not problem with Windows installer, but Linux file lost its extension. For example I rename thunderbird-3.1.3.tar to thunderbird-3.1.3.be.tar and file type has "bz2 file" in dialog. After downloading I have thunderbird-3.1.3.be.tar file on disk. ".bz2" extension is lost. I have manually type "thunderbird-3.1.3.be.tar.bz2" in dialog to save a file with the extension.

Comment 6

[Nicolas Mandil (:NicolasWeb)]

(In reply to comment #5)
As this is now confirmed by Siarhei, can one of you change the status to new and request blocking for 2.0 ?

(Why can't I do that even if I'm the one that reported this bug ? Just want to improve my use of bugzilla... trying to find out why in http://www.bugzilla.org/docs/3.6/en/html/bug_status_workflow.html without success)

Comment 7

[Alex Limi (:limi) — Firefox UX Team]

Please don't add random issues to the papercut metabugs, that's not why they exist. The paper cut set of bugs is supposed to be a manageable, prioritized list, not a way to get your pet peeve bug fixed.

Comment 8

[Nicolas Mandil (:NicolasWeb)]

Sorry Limi, I'll email you, so I can better understand why this is not part of paper cut... :-S

Comment 9

[Nicolas Mandil (:NicolasWeb)]

(In reply to Dave Webber from comment #3)
> The cause of the issue here, as I see it, is that the whole default filename
> is initially selected, when the part preceding the extension should be
> initially selected instead. If the pre-.ext part of the default filename was
> initially selected instead, then users wouldn't tend to accidentally replace
> the suffix when they type a new filename. This would bring the Save As
> dialogue closer to parity with Safari, and more in line with the expected
> user interface in Mac OS X in general. (The issue of the missing "Hide
> extension" checkbox would remain, but that's outside this topic; perhaps
> I'll file a bug on that later.)

This bug still exists in Fx 35 and OSX 10.10.1
However, the 'hide extension' checkbox is no more part of OSX UI.

Shouldn't this bug status be NEW (as of comment #3 and comment #5) ?
Is that enough easy to be a [good first bug] ?

Comment 10

[Nicolas Mandil (:NicolasWeb)]

please check comment #9 to tell if you can help.

Comment 11

[Julien Wajsberg [:julienw]]

Looks like a MacOS X-specific bug -- let's see if the Widget: Cocoa component is better.

Comment 12

[Dave Webber]

(In reply to Nicolas Mandil (:NicolasWeb) from comment #9)
> (In reply to Dave Webber from comment #3)
> > [snip]
> 
> This bug still exists in Fx 35 and OSX 10.10.1
> However, the 'hide extension' checkbox is no more part of OSX UI.

I don't have an copy of OS X 10.10.x running currently, but the "Hide extension" checkbox is still present in the standard UI in OS X 10.9.x (where "standard" could be read to mean that it is present in the expanded Save dialog every document-based application from Apple that I use, such as TextEdit, as well as applications I don't use, such as Safari). 

The "Hide extension" checkbox defaults to selected. On deselecting it, the suffix appears in the filename ("$verb As") text input, but the selection is *not* extended to include the suffix. The dialog "remembers" the state of the of "Hide extension" checkbox, and if it was left unchecked, the selection defaults to the portion of the filename preceding the extension. 

(In reply to Nicolas Mandil (:NicolasWeb) from comment #10)
> please check comment #9 to tell if you can help. 

Sorry to be so slow to reply. As a full-time student, I don't often check email accounts which aren't connected to school or employment. 

I haven't made nontrivial contributions to a major project written in C++ since childhood, and haven't yet had the impetus to learn Cocoa. While I've used JavaScript on-and-off about as long as it's existed, my last major web-dev project preceded the buzzword "Web 2.0". I doubt much of Firefox is written in R, Maxima, Octave, Perl, Scheme, Common Lisp, or any SQL dialect or spreadsheet language. However, I do spend every spare waking moment on extracurricular research and study, and most of the rest of my waking hours on curricular research and study, so what's a little more? What sort of help are you asking about?

Comment 13

[Dave Webber]

Attachment: Save As dialog on Mac OS X 10.9.5 with "Hide extension" checked and default portion of filename selected

Comment 14

[Dave Webber]

Attachment: Save As dialog on Mac OS X 10.9.5 with "Hide extension" *unchecked* and default portion of filename selected

Comment 16

[Tracy Walker [:tracy]]

"Hide Extension" option no longer exists on Mac 10.11; confirmed with Safari, TextEdit and Mozilla Nightly.  Marking P4 though by the time anyone gets to it, 10.9 may be unsupported.

Comment 17

[Wevah (Nate Weaver)]

This might have been fixed by the checkin for bug 426680.