426680 - [10.5/Minefield] In Save window the file extension is selected when it shouldn't

Status: RESOLVED FIXED

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

Description

[Rotis]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008040204 Minefield/3.0pre

When saving a photo, Minefield calls the OSX Save window. But there it should only select the file name for possible change, not the file extension with it. For example:

Right: "filename".jpg     Wrong: "filename.jpg"

Minefield does it wrong, Firefox 2.0.0.13 does it right.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Rotis]

Attachment: How it is in Minefield (wrong)

Comment 2

[Rotis]

Attachment: How it should be in Minefield (right)

Comment 3

[Marcia Knous [:marcia]]

Confirming, as I see the difference between branch and the latest nightly as the reporter does. I compared it to what Safari does, but in Safari's case they don't add any extension to the file name when I try to save a jpg file from google images.

Comment 4

[Rotis]

I would prefer to see the original file name when saving a file, not something manipulated like Safari does. For example: I save an image file from Flickr. It's name is usually something like "453637_673h34h3n_8o3.jpg". This is a crazy name, but with the extension ".jpg" I know it is an image file. If there only were "453637_673h34h3n_8o3" grandma Josephine Doe using Firefox might wonder what that means. Firefox 2.0.0.13 handles saving of files perfectly.

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #3)
> I compared it to what Safari does, but in Safari's case they
> don't add any extension to the file name when I try to save a jpg file from
> google images.

Showing the extension probably depends on the state of your "Hide Extension" preferences (either globally or in Safari's save dialogue).

Comment 6

[Rotis]

FF3 Final is coming June 17 and this bug introduced with FF3 will stay? No more comfortable image downloads due to FF's violating of MacOSX's 'human interface guidelines' (meaning the basic functions all programs should support). Since all the updates of a Firefox Final are just security fixes Mac users have to wait until 2009 when hopefully this FF3 bug might be fixed in FF4? Of course FF4 won't support PowerPC Macs anymore so all PPC Mac users who download a lot of images (from Flickr etc) are now stuck in FF2? Great! :-/

Comment 9

[RobertJ]

This bug is in FF3.0.x and 3.1 beta 3 on OSX. IT IS NOT IN FF2 on OSX. I don't know it that makes it a regression issue but thought it worth mentioning.

Comment 10

[Gingerbread Man]

This also applies to Firefox on Windows Vista (and probably Windows 7, although I haven't tested). I tried with 3.5.5, and the latest 3.6b4pre and 3.7a1pre nightlies, whatever they are at the time of this writing. Does anyone know if I'm supposed to file a separate bug report or what?

Comment 11

[Chris Lawson (gone)]

(In reply to comment #10)
> This also applies to Firefox on Windows Vista (and probably Windows 7, although
> I haven't tested). I tried with 3.5.5, and the latest 3.6b4pre and 3.7a1pre
> nightlies, whatever they are at the time of this writing. Does anyone know if
> I'm supposed to file a separate bug report or what?

Since this bug is Mac-only, it'd be great if you'd file a new bug report. Thanks for looking into it!

Comment 12

[Gingerbread Man]

(In reply to comment #11)
Thank you for the reply, but unfortunately I misspoke.

Although the extension portion of the file name is not selected when renaming files in Windows Explorer, it is selected in the Save As dialog of every other application -- including Internet Explorer. That suggests it may not be possible for developers to customize which portion of the file name is selected.

Additionally, when a file name without an extension is entered and the Save button is pressed, the extension for the currently selected file type is automatically appended. That makes this a non-issue on Windows, or a minor cosmetic one at best.

Thanks again, and I'll get out of your bug report now.

Comment 13

[dabraham]

I was wondering, since the camino guys seem to have fixed this in https://bugzilla.mozilla.org/show_bug.cgi?id=576978 would it be possible to use the same fix here?  Thank you very much.

Comment 15

[Wevah (Nate Weaver)]

Attachment: Patch v1

Only thing I'm not sure of is if all extensions should be allowed, especially for the case where no UTI matches the given extension.

Comment 16

[Markus Stange [:mstange]]

Comment on attachment 8772009 [details] [diff] [review]
Patch v1

Review of attachment 8772009 [details] [diff] [review]:
-----------------------------------------------------------------

Not sure about your question, but this patch makes things strictly better so let's land it.

::: widget/cocoa/nsFilePicker.mm
@@ +460,5 @@
>    NSString* defaultFilename = [NSString stringWithCharacters:(const unichar*)inDefaultName.get() length:inDefaultName.Length()];
>  
> +  // set up allowed types; this prevents the extension from being selected
> +  // use the UTI for the file type to allow alternate extensions (e.g., jpg vs. jpeg)
> +  NSString *extension = defaultFilename.pathExtension;

star goes on the left

Comment 17

[Wevah (Nate Weaver)]

The stars in that file are inconsistent, fwiw. :)

I can change and resubmit, but might as well just fix it up on your end.

Comment 18

[Wevah (Nate Weaver)]

Re: my question: If the user changes the extension to something that doesn't match the type, it pops a dialog. E.g., if the type's extension is "foo" and they change it to "bar" it'll ask if they want to save as ".foo" or ".bar.foo".

Comment 19

[Stefan [:stefanh]]

(In reply to Wevah from comment #17)
> The stars in that file are inconsistent, fwiw. :)
> 
> I can change and resubmit, but might as well just fix it up on your end.

If you submit a patch with user/commit message and set the checkin-needed keyword, the patch will be checked in to one of the integration repos. Then the patch will end up in mozilla-central when the integration repo is merged to mozilla-central.

Comment 20

[Wevah (Nate Weaver)]

Ah, cool. Thanks.

Comment 21

[Wevah (Nate Weaver)]

Attachment: file-extensions-v2.patch

Moved the stars.

Proposed commit message:

Bug 426680 - Set allowedFileTypes on NSSavePanel so the file extension isn't selected.

Comment 22

[Wevah (Nate Weaver)]

Oh, user should be "Nate Weaver"; email address can either be the one here or with "mix" replaced with "wevah" (might be better).

Comment 23

[Wevah (Nate Weaver)]

Ugh, "mix" = "moz".

Comment 24

[Stefan [:stefanh]]

Sorry, when I said "patch with user/commit message I ment a changeset with a commit message. You can create a changeset by 'hg commit -m "Bug 426680 - Set allowedFileTypes on NSSavePanel so the file extension isn't selected. r=mstange." && hg export > mypatch.diff'. 

('hg strip' will get rid of the commit)

Comment 25

[Stefan [:stefanh]]

Actually, never mind. I can push the patch to inbound for you :-)

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/666ed766fc72
Set allowedFileTypes on NSSavePanel so the file extension isn't selected. r=mstange.

Comment 27

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/666ed766fc72

Comment 28

[Wevah (Nate Weaver)]

(In reply to Stefan [:stefanh] from comment #24)
> Sorry, when I said "patch with user/commit message I ment a changeset with a
> commit message. You can create a changeset by 'hg commit -m "Bug 426680 -
> Set allowedFileTypes on NSSavePanel so the file extension isn't selected.
> r=mstange." && hg export > mypatch.diff'. 
> 
> ('hg strip' will get rid of the commit)

Oh, sorry! My fault.

Thanks for checking this in!