77474 - Composer does not save HTML file with HTML extension

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect)

Description

[David Park]

Using build 2001042304

When saving an HTML file from composer, the file extension of HTM is not added
to the file.  Thus, the file does not appear on the list when using file open
feature.

Comment 1

[Kathleen :Brade]

-->Charley (for a response on this issue)

Comment 2

[Charles Manske]

We use ".html", not ".htm" as part of the suggested filename when saving a file.
Windows operating systems hide that by default, which IMHO is an awful feature
that causes lots of confusion. This may be the source of your observation.
If the user changes the ".html" to something else, we don't change it.
People may want to use ".shtml" etc., so I don't think we should be any more
aggressive in modifying the extension.

Comment 3

[David Park]

The bad part or this is that the 'html' document you just created in Composer is
not visible when you try to open a document.  The behavior seems different using
4.x composer so something doesn't jive here.

Comment 4

[Charles Manske]

Please clarify -- I don't understand your last comment.

Comment 5

[Kathleen :Brade]

David Park--are you saying that after you save it, if you go to "open" within 
Composer you don't see the file?  Please clarify where you don't see the file.

Also, can you change or set the extension when being prompted for the file name?

Comment 6

[Charles Manske]

David: When you use an "Open" or "Save" dialog, do you see file extensions for
html files? Do you have the "Hide files of these types" turned on for html
files in your Explorer View | Options [File types tab]?

Comment 7

[David Park]

Using build #2001042304, this seems to be fixed.  When I save, defaults to HTML
files.  When opening a file, the file is now visible with the correct file icon.

Comment 8

[Charles Manske]

I wonder if there was ever anything "broken" no changes were made to this code!
Oh well!

Comment 9

[David Park]

Strange.  La Guardia and I both witnessed the problem.  That was an easy one to fix!

Comment 10

[sujay]

verified.

Comment 11

[David Park]

Using build 2001043004.

This problem seems to happen again.
1.  Create file in composer and save to default format, HTML
2.  Attempt to open file and the file I just created does not appear on the file
list window.  The file does appear when I specify 'all files'.
3.  Viewing properties on the file, the MIME does not seem to be set.

Comment 12

[Charles Manske]

Please repeat your test: after you find a file that is not showing up in the
open dialog with "html" type set, tell me the exact filename you used and
attach that file to this bug.

Comment 13

[David Park]

Attachment: test file 'ab' created in Composer

Comment 14

[David Park]

Basically, I've discovered that Composer is not adding the .html extension even
though the file type defaults to it.

Comment 15

[Charles Manske]

The only time there is a real problem is when Windows Explorer is configured to
"hide all extensions". In that case, if user edits the filename, the "hidden"
".html" that we added is wiped out. I still don't think we should force ".htm"
or ".html" in all cases, so I will fix it in the case that there is no file
extension at all after leaving the Open file dialog. Patch comming.

Comment 16

[Charles Manske]

Attachment: Append ".html" only if extension is missing

Comment 17

[Charles Manske]

What a pain. Suggested fix isn't adequate. If we append ".html", we have to test
if file exists (again), else we fail to save the file. I'm going to look into
putting this stuff into nsIFilePicker implementation.

Comment 18

[Charles Manske]

Attachment: Check for saving HTML and append ".html" if no extension -- Windows only version of nsFilePicker

Comment 19

[Charles Manske]

Fix the bug in Windows-only filepicker code. This is real ugly, since we have
 to do our own UI for overwrite detection. Otherwise, user would edit filename,
be warned that they were replacing a file, but that isn't really true if they
don't have an extension, because we auto-append ".html" in that case. Thus we
have to do our own overwrite dialog. It looks the same as the one Windows puts
up, exept that I included a "Cancel" button. Note that if they answer "no" to
"Do you want to replace file?", we relaunch the save dialog. So behavior is as
close as possible as the built-in overwrite prompt, except that we can't keep
the save dialog active when we put up our overwrite prompt.
This stuff will happen when saving to html filetype for ALL modules, not just
Composer.
Question: Should we "rescue" any other extensions besides the html types?
Bill Law should review this.

Comment 20

[Charles Manske]

Attachment: Much simpler fix. Utilizes "lpstrDefExt" to append extension

Comment 21

[Charles Manske]

So the  5/04 patch uses Window's built-in default extension handling.
I still do it only when suggested name contains ".html" or ".htm" or ".shtml".
The described behavior is that the extension will be applied if user doesn't
supply one, but that's not exactly true. It often appends ".html" even if you
have an extension. The state of the file filter seems to have some effect, and
if user wants the exact name (e.g., to save as "foo.shtml") then they have to
put quotes around their filename. So this is the same annoying behavior that we
see in Wordpad when trying to save text files with extensions other than ".txt"!
Note also that I still think it's good to checkin the changes to
filepicker.properties
Someone is bound to need the "No" button (to do a "Yes", "No", "Cancel" dialog)
and the "\n" in the overwrite prompt string line-breaks the message exactly
as the internal Windows dialog does.

Comment 22

[kinmoz]

I'm ok with this "workaround" for now, as long as the module owner is (note the
conditional sr=kin), but I think that we really need to have some sort of
generic API that allows us to set up a default extension to use when saving.
Other apps will will be using this stuff and they may need to do this same thing
with other file types/extensions. (.xml, .cgi, .asp, etc.)

If we check this in as is, could we add a comment to the code that mentions this?

Also, we need to look into whether or not the operator==() string compares are
still allowed. I thought people were being steered towards the more explicit
Equals() methods.

Comment 23

[Charles Manske]

Attachment: Alternate fix: Use "EqualsIgnoreCase" and add comments about generate HTML types.

Comment 24

[Bill Law]

r=law

I think there's some sort of perverse "logic" behind Windows' file picker
behavior.  If you enter an "extension" that Windows doesn't know about, then it
seems to think it's not an extension and will append the default.  It might also
automagically select its own default if you select a file type (it seems to want
to pick the one associated with the file type).  Some of this might be under
application control so you won't see the same thing with all apps.

Anyway, I'm glad this simpler fix seems to do the job.

Comment 25

[kinmoz]

sr=[e-mail] on the new patch. Thanks charley!

Comment 26

[Charles Manske]

Discussed and reviewed. Will checkin 5/7 patch.

Comment 27

[timeless]

the logic used by windows is nowhere near that simple.
however if you enter "filename.ext" [including quotes] it will treat that as 
the filename (whereas filename.ext might get another extension).

I think it might relate to whether you show file extension in explorer (because 
of late i've typed extensions in notepad w/o quotes and it's treat them as 
complete files).

Comment 28

[Charles Manske]

checked in.

Comment 29

[Charles Manske]

cleanup status

Comment 30

[sujay]

verified.