Closed Bug 77474 Opened 20 years ago Closed 20 years ago

Composer does not save HTML file with HTML extension

Categories

(Core :: DOM: Editor, defect)

x86
Other
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla0.9.1

People

(Reporter: dyp, Assigned: cmanske)

Details

Attachments

(5 files)

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.
-->Charley (for a response on this issue)
Assignee: beppe → cmanske
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.
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.
Please clarify -- I don't understand your last comment.
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?
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]?
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.
I wonder if there was ever anything "broken" no changes were made to this code!
Oh well!

Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
Strange.  La Guardia and I both witnessed the problem.  That was an easy one to fix!
verified.
Status: RESOLVED → VERIFIED
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.
Status: VERIFIED → UNCONFIRMED
Resolution: INVALID → ---
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.
Basically, I've discovered that Composer is not adding the .html extension even
though the file type defaults to it.
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.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → mozilla0.9.1
Keywords: patch, review
Whiteboard: FIX IN HAND need r=, sr=
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.
Keywords: patch, review
Whiteboard: FIX IN HAND need r=, sr=
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.
Keywords: patch, review
Whiteboard: FIX IN HAND need r=, sr=
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.

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.
Whiteboard: FIX IN HAND need r=, sr= → FIX IN HAND need r=
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.
sr=kin@netscape.com on the new patch. Thanks charley!
Discussed and reviewed. Will checkin 5/7 patch.
Whiteboard: FIX IN HAND need r= → FIX IN HAND
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).
checked in.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
cleanup status
Keywords: patch, review
Whiteboard: FIX IN HAND
verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.