Enable "Hide Extension" option when "Save Link As" on the Mac

Enable "Hide Extension" option when "Save Link As" on the Mac

When you choose "Save Link As..." on the Mac, the file picker includes
an option to hide the downloaded file's extension in the Finder. This
cl propagates this boolean so that the downloaded file, at the end of
the download process, has its file extension hidden.

To make it easier to understand what I did to implement this
change, the following describes how the "Hide Extension" flag makes it
from the file picker dialog to the point at which the download file's
extension gets hidden.

The "Hide Extension" setting comes from the Mac version of
SelectFileDialogImpl::FileWasSelected(), which stores it in a
ui::SelectedFileInfo that's returned to the DownloadFilePicker via
its FileSelectedWithExtraInfo() method.

FileSelectedWithExtraInfo() extracts the flag and passes it to
DownloadFilePicker's OnFileSelected() method, which passes the flag to
its file_selected_callback_, which is a call to
DownloadTargetDeterminer's PromptUserForDownloadPathDone() method,
defined by the FileSelectedCallback interface.

The DownloadTargetDeterminer stashes the "Hide Extension" flag until its
state machine completes at ScheduleCallbackAndDeleteSelf(), where it
calls its completion_callback_. It places the flag inside the
DownloadTargetInfo which is a parameter to the callback.

The callback invokes ChromeDownloadManagerDelegate's
OnDownloadTargetDetermined() method, which sends the flag to its
callback, which is defined in DownloadTargetCallback. This same
interface is redeclared by DownloadItemImpl, which allows a DownloadItem
to be the callback destination of the DownloadTargetDeterminer. The
callback invokes DownloadItemImpl::OnDownloadTargetDetermined(), which
stores the flag in a DownloadFile (DownloadFile actually stores the flag
in the BaseFile that it wraps; this is where the flag is ultimately
needed anyway).

Eventually DownloadFileImpl::RenameWithRetryInternal() calls
file_.AnnotateWithSourceInformation(). base_file_mac.cc's modified
version of this method now calls the newly-added
SetExtensionHiddenForFile() if the BaseFile’s "Hide Extension" flag is
true.
 
The changes to the other classes, unittests, and browsertests are
unfortunate collateral damage resulting from piping the "Hide Extension"
flag through so many interfaces.

BUG=540874

[shrike, 2015-12-11 20:28:52]

Description was changed from

==========
Enable "Hide Extension" option when "Save Link As" on the Mac

This change involves propagating the "Hide Extension" boolean from the
Mac version of the SelectFileDialog all the way to BaseFile, where it
can be acted upon at the end of the download. I was able to hide the
boolean within the SelectedFileInfo struct which allowed me to avoid
changing interfaces but eventually the APIs started propagating naked
file paths, which meant adding a boolean. The bulk of the _unittest
file changes are a result of the extra boolean added to the APIs.

BUG=540874
==========

to

==========
Enable "Hide Extension" option when "Save Link As" on the Mac

This change involves propagating the "Hide Extension" boolean from the
Mac version of the SelectFileDialog all the way to BaseFile, where it
can be acted upon at the end of the download. I was able to hide the
boolean within the SelectedFileInfo struct which allowed me to avoid
changing interfaces but eventually the APIs started propagating naked
file paths, which meant adding a boolean. The bulk of the _unittest
file changes are a result of the extra boolean added to the APIs.

To make it easier to understand what I had to do to implement this
change, the following describes how the "Hide Extension" flag makes it
from the file picker dialog to the point at which the download file's
extension gets hidden.

The "Hide Extension" setting comes from the Mac version of
SelectFileDialogImpl::FileWasSelected(), which stores it in a
ui::SelectedFileInfo that's returned to the DownloadFilePicker via
its FileSelectedWithExtraInfo() method.

FileSelectedWithExtraInfo() extracts the flag and passes it to
DownloadFilePicker's OnFileSelected() method, which passes the flag to
its file_selected_callback_, which is a call to
DownloadTargetDeterminer's PromptUserForDownloadPathDone() method,
defined by the FileSelectedCallback interface.

The DownloadTargetDeterminer stashes the "Hide Extension" flag until its
state machine completes at ScheduleCallbackAndDeleteSelf(), where it
calls its completion_callback_. It places the flag inside the
DownloadTargetInfo which is a parameter to the callback.

The callback invokes ChromeDownloadManagerDelegate's
OnDownloadTargetDetermined() method, which sends the flag to its
callback, which is defined in DownloadTargetCallback. This same
interface is redeclared by DownloadItemImpl, which allows a DownloadItem
to be the callback destination of the DownloadTargetDeterminer. The
callback invokes DownloadItemImpl::OnDownloadTargetDetermined(), which
stores the flag in a DownloadFile (DownloadFile actually stores the flag
in the BaseFile that it wraps; this is where the flag is ultimately
needed anyway).

Eventually DownloadFileImpl::RenameWithRetryInternal() calls
file_.AnnotateWithSourceInformation(). base_file_mac.cc's modified
version of this method now calls the newly-added
SetExtensionHiddenForFile() if the BaseFile’s "Hide Extension" flag is
true.
 
The changes to the other classes, unittests, and browsertests are
unfortunate collateral damage resulting from piping the "Hide Extension"
flag through so many interfaces.

BUG=540874
==========

[shrike, 2015-12-11 20:28:52]

shrike@chromium.org changed reviewers:
+ avi@chromium.org, jochen@chromium.org, phajdan.jr@chromium.org

[shrike, 2015-12-11 20:31:44]

Description was changed from

==========
Enable "Hide Extension" option when "Save Link As" on the Mac

This change involves propagating the "Hide Extension" boolean from the
Mac version of the SelectFileDialog all the way to BaseFile, where it
can be acted upon at the end of the download. I was able to hide the
boolean within the SelectedFileInfo struct which allowed me to avoid
changing interfaces but eventually the APIs started propagating naked
file paths, which meant adding a boolean. The bulk of the _unittest
file changes are a result of the extra boolean added to the APIs.

To make it easier to understand what I had to do to implement this
change, the following describes how the "Hide Extension" flag makes it
from the file picker dialog to the point at which the download file's
extension gets hidden.

The "Hide Extension" setting comes from the Mac version of
SelectFileDialogImpl::FileWasSelected(), which stores it in a
ui::SelectedFileInfo that's returned to the DownloadFilePicker via
its FileSelectedWithExtraInfo() method.

FileSelectedWithExtraInfo() extracts the flag and passes it to
DownloadFilePicker's OnFileSelected() method, which passes the flag to
its file_selected_callback_, which is a call to
DownloadTargetDeterminer's PromptUserForDownloadPathDone() method,
defined by the FileSelectedCallback interface.

The DownloadTargetDeterminer stashes the "Hide Extension" flag until its
state machine completes at ScheduleCallbackAndDeleteSelf(), where it
calls its completion_callback_. It places the flag inside the
DownloadTargetInfo which is a parameter to the callback.

The callback invokes ChromeDownloadManagerDelegate's
OnDownloadTargetDetermined() method, which sends the flag to its
callback, which is defined in DownloadTargetCallback. This same
interface is redeclared by DownloadItemImpl, which allows a DownloadItem
to be the callback destination of the DownloadTargetDeterminer. The
callback invokes DownloadItemImpl::OnDownloadTargetDetermined(), which
stores the flag in a DownloadFile (DownloadFile actually stores the flag
in the BaseFile that it wraps; this is where the flag is ultimately
needed anyway).

Eventually DownloadFileImpl::RenameWithRetryInternal() calls
file_.AnnotateWithSourceInformation(). base_file_mac.cc's modified
version of this method now calls the newly-added
SetExtensionHiddenForFile() if the BaseFile’s "Hide Extension" flag is
true.
 
The changes to the other classes, unittests, and browsertests are
unfortunate collateral damage resulting from piping the "Hide Extension"
flag through so many interfaces.

BUG=540874
==========

to

==========
Enable "Hide Extension" option when "Save Link As" on the Mac

When you choose "Save Link As..." on the Mac, the file picker includes
an option to hide the downloaded file's extension in the Finder. This
cl propagates this boolean so that the downloaded file, at the end of
the download process, has its file extension hidden.

To make it easier to understand what I did to implement this
change, the following describes how the "Hide Extension" flag makes it
from the file picker dialog to the point at which the download file's
extension gets hidden.

The "Hide Extension" setting comes from the Mac version of
SelectFileDialogImpl::FileWasSelected(), which stores it in a
ui::SelectedFileInfo that's returned to the DownloadFilePicker via
its FileSelectedWithExtraInfo() method.

FileSelectedWithExtraInfo() extracts the flag and passes it to
DownloadFilePicker's OnFileSelected() method, which passes the flag to
its file_selected_callback_, which is a call to
DownloadTargetDeterminer's PromptUserForDownloadPathDone() method,
defined by the FileSelectedCallback interface.

The DownloadTargetDeterminer stashes the "Hide Extension" flag until its
state machine completes at ScheduleCallbackAndDeleteSelf(), where it
calls its completion_callback_. It places the flag inside the
DownloadTargetInfo which is a parameter to the callback.

The callback invokes ChromeDownloadManagerDelegate's
OnDownloadTargetDetermined() method, which sends the flag to its
callback, which is defined in DownloadTargetCallback. This same
interface is redeclared by DownloadItemImpl, which allows a DownloadItem
to be the callback destination of the DownloadTargetDeterminer. The
callback invokes DownloadItemImpl::OnDownloadTargetDetermined(), which
stores the flag in a DownloadFile (DownloadFile actually stores the flag
in the BaseFile that it wraps; this is where the flag is ultimately
needed anyway).

Eventually DownloadFileImpl::RenameWithRetryInternal() calls
file_.AnnotateWithSourceInformation(). base_file_mac.cc's modified
version of this method now calls the newly-added
SetExtensionHiddenForFile() if the BaseFile’s "Hide Extension" flag is
true.
 
The changes to the other classes, unittests, and browsertests are
unfortunate collateral damage resulting from piping the "Hide Extension"
flag through so many interfaces.

BUG=540874
==========

[shrike, 2015-12-11 20:35:43]

Hello,

PTAL and let me know your thoughts on this cl. Thank you.

[Avi (use Gerrit), 2015-12-12 00:41:46]

Random Mac nit-picky stuff.

It's unfortunate that we have that boolean *everywhere* now, that we don't have
some big struct that holds file data.

https://codereview.chromium.org/1513413002/diff/1/content/browser/download/fi...
File content/browser/download/file_metadata_mac.mm (right):

https://codereview.chromium.org/1513413002/diff/1/content/browser/download/fi...
content/browser/download/file_metadata_mac.mm:173: NSNumber* boolNumber =
[NSNumber numberWithBool:hidden ? YES : NO];
bool ? YES : NO is not useful; bools convert as 1 and 0, which are YES and NO.

Couldn't you just do "@(hidden)" below?

https://codereview.chromium.org/1513413002/diff/1/content/browser/download/fi...
content/browser/download/file_metadata_mac.mm:176:
forKey:NSFileExtensionHidden];
NSDictionary* attributes = @{ NSFileExtensionHidden : @(hidden) };

should work.

https://codereview.chromium.org/1513413002/diff/1/content/browser/download/fi...
File content/browser/download/file_metadata_unittest_mac.mm (right):

https://codereview.chromium.org/1513413002/diff/1/content/browser/download/fi...
content/browser/download/file_metadata_unittest_mac.mm:45: : false;
Again, not needed. You can straight-up assign a BOOL to a bool.

https://codereview.chromium.org/1513413002/diff/1/content/browser/download/fi...
content/browser/download/file_metadata_unittest_mac.mm:53: : false;
Ditto.

[jochen (gone - plz use gerrit), 2015-12-14 12:30:52]

jochen@chromium.org changed reviewers:
+ rdsmith@chromium.org

[jochen (gone - plz use gerrit), 2015-12-14 12:30:53]

+rdsmith for downloads

[Randy Smith (Not in Mondays), 2015-12-14 12:34:04]

rdsmith@chromium.org changed reviewers:
+ asanka@chromium.org
- rdsmith@chromium.org

[Randy Smith (Not in Mondays), 2015-12-14 12:34:04]

Lateralling to Asanka, who knows the Downloads UI code in general, and several
of the files in this CL in particular, better than I.

[asanka, 2015-12-16 02:54:26]

https://codereview.chromium.org/1513413002/diff/1/ui/shell_dialogs/select_fil...
File ui/shell_dialogs/select_file_dialog_mac.mm (right):

https://codereview.chromium.org/1513413002/diff/1/ui/shell_dialogs/select_fil...
ui/shell_dialogs/select_file_dialog_mac.mm:155: if ([dialog isExtensionHidden])
{
Doesn't this mean that the user has chosen to expose or hide extensions in the
NSSavePanel (i.e. a setting that's ephemeral and only applying to save dialogs
for Chrome/Chromium)? Why do we need to use it to set the NSFileExtensionHidden
attribute on the file on disk?

[shrike, 2015-12-16 18:40:46]

On 2015/12/12 00:41:46, Avi wrote:
> Random Mac nit-picky stuff.
> 
> It's unfortunate that we have that boolean *everywhere* now, that we don't
have
> some big struct that holds file data.

Agreed :-/ .

[shrike, 2015-12-16 19:04:12]

https://codereview.chromium.org/1513413002/diff/1/content/browser/download/fi...
File content/browser/download/file_metadata_mac.mm (right):

https://codereview.chromium.org/1513413002/diff/1/content/browser/download/fi...
content/browser/download/file_metadata_mac.mm:173: NSNumber* boolNumber =
[NSNumber numberWithBool:hidden ? YES : NO];
On 2015/12/12 00:41:46, Avi wrote:
> bool ? YES : NO is not useful; bools convert as 1 and 0, which are YES and NO.
> 
> Couldn't you just do "@(hidden)" below?

Acknowledged.

https://codereview.chromium.org/1513413002/diff/1/content/browser/download/fi...
content/browser/download/file_metadata_mac.mm:176:
forKey:NSFileExtensionHidden];
On 2015/12/12 00:41:46, Avi wrote:
> NSDictionary* attributes = @{ NSFileExtensionHidden : @(hidden) };
> 
> should work.

Done.

https://codereview.chromium.org/1513413002/diff/1/content/browser/download/fi...
File content/browser/download/file_metadata_unittest_mac.mm (right):

https://codereview.chromium.org/1513413002/diff/1/content/browser/download/fi...
content/browser/download/file_metadata_unittest_mac.mm:45: : false;
On 2015/12/12 00:41:46, Avi wrote:
> Again, not needed. You can straight-up assign a BOOL to a bool.

Acknowledged.

https://codereview.chromium.org/1513413002/diff/1/content/browser/download/fi...
content/browser/download/file_metadata_unittest_mac.mm:53: : false;
On 2015/12/12 00:41:46, Avi wrote:
> Ditto.

Acknowledged.

https://codereview.chromium.org/1513413002/diff/1/ui/shell_dialogs/select_fil...
File ui/shell_dialogs/select_file_dialog_mac.mm (right):

https://codereview.chromium.org/1513413002/diff/1/ui/shell_dialogs/select_fil...
ui/shell_dialogs/select_file_dialog_mac.mm:155: if ([dialog isExtensionHidden])
{
On 2015/12/16 02:54:26, asanka wrote:
> Doesn't this mean that the user has chosen to expose or hide extensions in the
> NSSavePanel (i.e. a setting that's ephemeral and only applying to save dialogs
> for Chrome/Chromium)? Why do we need to use it to set the
NSFileExtensionHidden
> attribute on the file on disk?

The "Hide Extension" checkbox does not hide extensions in the NSSavePanel
(notice that toggling it does not hide the file extensions of files listed in
the file browser). Rather, it is an option that allows the user to say whether
or not they want the file extension visible for the file they are about to
create. It is then up to the application to hide the extension once the file has
been created.

[shrike, 2016-01-19 19:38:17]

Hello reviewers, Happy New Year! Can you give me some feedback on this cl?

[shrike, 2016-02-04 19:28:08]

Reviewers, this cl has made no progress for about 6 weeks. I would appreciate
you taking a look at it now.

[jochen (gone - plz use gerrit), 2016-02-05 14:49:46]

asanka, can you have another look?

[asanka, 2016-02-05 19:15:10]

Can a Mac person confirm that this is in fact desired behavior? It looks like
this CL is taking the property returned by [NSSavePanel isExtensionHidden] and
then using it to manually hide the extension of the downloaded file. Before we
review the download code, I'd like to have some confirmation that this is the
intended behavior.

Looking at the documentation for NSSavePanel's isExtensionHidden getter, I see:

"  When the value of this property is YES, the extension-hiding checkbox is
visible and checked. You should rarely set this property, because the state is
saved on a per-application basis. Setting this property has no effect if the
user has chosen to show all file extensions in Finder. "

I see nothing indicating that the caller should take this value and then use it
to manually hide the extension of the resulting filename. So what gives?

[shrike, 2016-02-05 20:05:14]

On 2016/02/05 19:15:10, asanka wrote:
> Can a Mac person confirm that this is in fact desired behavior? It looks like
> this CL is taking the property returned by [NSSavePanel isExtensionHidden] and
> then using it to manually hide the extension of the downloaded file. Before we
> review the download code, I'd like to have some confirmation that this is the
> intended behavior.
> 
> Looking at the documentation for NSSavePanel's isExtensionHidden getter, I
see:
> 
> "  When the value of this property is YES, the extension-hiding checkbox is
> visible and checked. You should rarely set this property, because the state is
> saved on a per-application basis. Setting this property has no effect if the
> user has chosen to show all file extensions in Finder. "
> 
> I see nothing indicating that the caller should take this value and then use
it
> to manually hide the extension of the resulting filename. So what gives?

Are you asking for a Mac person to confirm that this is the desired behavior, or
a Mac person other than me to confirm it? I have been writing Mac OS X code for
the past 15 years, and before that spent 11 years writing code for the NeXT
Machine/Rhapsody while a developer at several of my own start-ups, as an
employee at NeXT Computer, and as a manager of a lab of NeXT Machines in 1989. I
can confirm to you that I am a Mac person, and that I am using this obscure bit
of API correctly.

Back when OS X first shipped there was a big stink about file extensions. The
Mac, up until that point, hid file type info within each file. With the switch
to OS X/UNIX, file type info was suddenly appended to the file name. So many Mac
users complained that Apple added the ability to hide file extensions. As OS X
has gotten on in years, the issue of visible file extensions isn't as big as it
once was. I think the lack of adequate documentation for this API is a result of
that. I also think this API is poorly worded.

I'm not sure what else to tell you beyond this. File extensions on the Mac are
hidden on a per-file basis. You can select a file in the Finder and hide the
extension of an existing file, or click the Hide Extension checkbox in the Save
Panel to hide the file extension of a file you are about to create. Toggling
that button in the Save Panel hides the file extension in the textfield where
you type the name of the new file, but it does *not* cause the file's extension
to actually be hidden in the file system (how could it - the Save Panel knows
nothing about what your app is doing to save the file, and so does not know when
it can hide the extension). It is up to the application to read the value of the
Hide Extension checkbox and configure the file system to hide the extension if
so directed. Nor does toggling the File Extension button govern the visibility
of file extensions in the Finder.

[asanka, 2016-02-05 22:03:50]

On 2016/02/05 20:05:14, shrike wrote:
> On 2016/02/05 19:15:10, asanka wrote:
> > Can a Mac person confirm that this is in fact desired behavior? It looks
like
> > this CL is taking the property returned by [NSSavePanel isExtensionHidden]
and
> > then using it to manually hide the extension of the downloaded file. Before
we
> > review the download code, I'd like to have some confirmation that this is
the
> > intended behavior.
> > 
> > Looking at the documentation for NSSavePanel's isExtensionHidden getter, I
> see:
> > 
> > "  When the value of this property is YES, the extension-hiding checkbox is
> > visible and checked. You should rarely set this property, because the state
is
> > saved on a per-application basis. Setting this property has no effect if the
> > user has chosen to show all file extensions in Finder. "
> > 
> > I see nothing indicating that the caller should take this value and then use
> it
> > to manually hide the extension of the resulting filename. So what gives?
> 
> Are you asking for a Mac person to confirm that this is the desired behavior,
or
> a Mac person other than me to confirm it? I have been writing Mac OS X code
for
> the past 15 years, and before that spent 11 years writing code for the NeXT
> Machine/Rhapsody while a developer at several of my own start-ups, as an
> employee at NeXT Computer, and as a manager of a lab of NeXT Machines in 1989.
I
> can confirm to you that I am a Mac person, and that I am using this obscure
bit
> of API correctly.
>
> Back when OS X first shipped there was a big stink about file extensions. The
> Mac, up until that point, hid file type info within each file. With the switch
> to OS X/UNIX, file type info was suddenly appended to the file name. So many
Mac
> users complained that Apple added the ability to hide file extensions. As OS X
> has gotten on in years, the issue of visible file extensions isn't as big as
it
> once was. I think the lack of adequate documentation for this API is a result
of
> that. I also think this API is poorly worded.
> 
> I'm not sure what else to tell you beyond this. File extensions on the Mac are
> hidden on a per-file basis. You can select a file in the Finder and hide the
> extension of an existing file, or click the Hide Extension checkbox in the
Save
> Panel to hide the file extension of a file you are about to create. Toggling
> that button in the Save Panel hides the file extension in the textfield where
> you type the name of the new file, but it does *not* cause the file's
extension
> to actually be hidden in the file system (how could it - the Save Panel knows
> nothing about what your app is doing to save the file, and so does not know
when
> it can hide the extension). It is up to the application to read the value of
the
> Hide Extension checkbox and configure the file system to hide the extension if
> so directed. Nor does toggling the File Extension button govern the visibility
> of file extensions in the Finder.

Thank you for the background. I don't mean to question your judgement on whether
this behavior is correct or not.

But this CL introduces a lot of Mac OS X plumbing for a behavior that was not
requested in a user bug report and one that isn't documented. At this point I'd
like to humbly request another Mac person (i.e. avi@) to evaluate whether this
behavior should be added to Chrome because I don't consider myself qualified to
make this call. Based on my layman's perspective I'm having a hard time seeing
how this [undocumented] behavior jives with user expectation given how unlikely
it is to be implemented correctly by someone who doesn't have the above
background.

avi: ^^^

If it is in fact a matter of correctness that is likely to affect our users,
then sure. If it's something that can be implemented in a manner that doesn't
involve threading through multiple architectural layers (unlikely), then great.
I think given all the layers involved, there's a non-negligible maintenance cost
to adding this, which is why I'm asking.

Once that's resolved, I'd be happy to review the rest of the CL.

[Avi (use Gerrit), 2016-02-06 07:05:51]

On 2016/02/05 22:03:50, asanka wrote:
> On 2016/02/05 20:05:14, shrike wrote:
> > On 2016/02/05 19:15:10, asanka wrote:
> > > Can a Mac person confirm that this is in fact desired behavior? It looks
> like
> > > this CL is taking the property returned by [NSSavePanel isExtensionHidden]
> and
> > > then using it to manually hide the extension of the downloaded file.
Before
> we
> > > review the download code, I'd like to have some confirmation that this is
> the
> > > intended behavior.
> > > 
> > > Looking at the documentation for NSSavePanel's isExtensionHidden getter, I
> > see:
> > > 
> > > "  When the value of this property is YES, the extension-hiding checkbox
is
> > > visible and checked. You should rarely set this property, because the
state
> is
> > > saved on a per-application basis. Setting this property has no effect if
the
> > > user has chosen to show all file extensions in Finder. "
> > > 
> > > I see nothing indicating that the caller should take this value and then
use
> > it
> > > to manually hide the extension of the resulting filename. So what gives?
> > 
> > Are you asking for a Mac person to confirm that this is the desired
behavior,
> or
> > a Mac person other than me to confirm it? I have been writing Mac OS X code
> for
> > the past 15 years, and before that spent 11 years writing code for the NeXT
> > Machine/Rhapsody while a developer at several of my own start-ups, as an
> > employee at NeXT Computer, and as a manager of a lab of NeXT Machines in
1989.
> I
> > can confirm to you that I am a Mac person, and that I am using this obscure
> bit
> > of API correctly.
> >
> > Back when OS X first shipped there was a big stink about file extensions.
The
> > Mac, up until that point, hid file type info within each file. With the
switch
> > to OS X/UNIX, file type info was suddenly appended to the file name. So many
> Mac
> > users complained that Apple added the ability to hide file extensions. As OS
X
> > has gotten on in years, the issue of visible file extensions isn't as big as
> it
> > once was. I think the lack of adequate documentation for this API is a
result
> of
> > that. I also think this API is poorly worded.
> > 
> > I'm not sure what else to tell you beyond this. File extensions on the Mac
are
> > hidden on a per-file basis. You can select a file in the Finder and hide the
> > extension of an existing file, or click the Hide Extension checkbox in the
> Save
> > Panel to hide the file extension of a file you are about to create. Toggling
> > that button in the Save Panel hides the file extension in the textfield
where
> > you type the name of the new file, but it does *not* cause the file's
> extension
> > to actually be hidden in the file system (how could it - the Save Panel
knows
> > nothing about what your app is doing to save the file, and so does not know
> when
> > it can hide the extension). It is up to the application to read the value of
> the
> > Hide Extension checkbox and configure the file system to hide the extension
if
> > so directed. Nor does toggling the File Extension button govern the
visibility
> > of file extensions in the Finder.
> 
> Thank you for the background. I don't mean to question your judgement on
whether
> this behavior is correct or not.
> 
> But this CL introduces a lot of Mac OS X plumbing for a behavior that was not
> requested in a user bug report and one that isn't documented. At this point
I'd
> like to humbly request another Mac person (i.e. avi@) to evaluate whether this
> behavior should be added to Chrome because I don't consider myself qualified
to
> make this call. Based on my layman's perspective I'm having a hard time seeing
> how this [undocumented] behavior jives with user expectation given how
unlikely
> it is to be implemented correctly by someone who doesn't have the above
> background.
> 
> avi: ^^^
> 
> If it is in fact a matter of correctness that is likely to affect our users,
> then sure. If it's something that can be implemented in a manner that doesn't
> involve threading through multiple architectural layers (unlikely), then
great.
> I think given all the layers involved, there's a non-negligible maintenance
cost
> to adding this, which is why I'm asking.
> 
> Once that's resolved, I'd be happy to review the rest of the CL.

It's a legitimate feature that Mac users are missing and would expect.

The question is how to do this is 1) a non-hacky way and 2) a non-intrusive way.

Can we satisfy both?