Open Bug 120313 Opened 23 years ago Updated 2 years ago

save page as text file should give file name .txt extension

Categories

(Core :: Widget, defect, P3)

defect

Tracking

()

REOPENED

People

(Reporter: jmd, Unassigned)

References

Details

(Whiteboard: [ADT3][tpi:+])

save page as text file should give file name .txt extention

Even with 'text file' save type persisting, Save as dialog pops up, naming the
file foo.html, or www.mozilla.org.html.

Expected: For hosts or directories with no filename, use [host|directory].txt
          For files, if file ends with ".html" or ".htm", remove such extention
          and add ".txt". Otherwise, just add ".txt" to whatever is already there.

Linux 2002011606 (post-massive-ben-saveas-fixes). ->ben.
I think the current naming scheme is fine but I do think that the *.html or
*.htm or *.shtml or whatever should be removed and *.txt should be added.  
Ben--I think Composer already has code that handles this case.
interestingly, not a problem on win2k [2002.01.24.09]. alas, unable to test on
mac due to bug 107521.
Keywords: nsbeta1
Summary: save page as text file should give file name .txt extention → save page as text file should give file name .txt extension
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.0
Of note -- the extension should be changed in the default string _before_ the
filepicker is posed.  Once the user picks a filename we should _not_ be changing
the user-selected filename on Linux.
*** Bug 126665 has been marked as a duplicate of this bug. ***
Duplicate is on WinNT.
OS: Linux → All
Hardware: PC → All
>Of note -- the extension should be changed in the default string _before_ the
>filepicker is posed

Which is hard, given that the user can make the decision to save as plain text
via the file picker.

This is related to that "misgiving" I expressed when asked to review bug 126260.
 You can't use lpstrDefExt on Win32 if the user can select different file types
that require different default extensions.

At least not without more effort.  I'm investigating a solution to that problem.
nsbeta1+ per ADT/Nav triage.
Keywords: nsbeta1nsbeta1+
ADT2 per ADT triage. Potential data loss.
Keywords: dataloss
Whiteboard: [ADT3]
Mass moving nsbeta1+/adt3 bugs assigned to Navigator team engineers out to
target milestone 1.0.1.  Please confine your attentions to driving down our list
of TM 1.0 bugs for beta.  Better to help, debug, or test one of them than fix
one of these.
Target Milestone: mozilla1.0 → mozilla1.0.1
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1-
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1+
Re #2: With 2002080419 this _is_ a problem on Win2K (SP2).  If I do a file, save
as on this page, the type starts off as text (having done this before), but the
suggested file name is show_bug.cgi.html.  This is wrong.

If I then selected any other file type, I would also expect the extension to be
updated accordingly.
*** Bug 141343 has been marked as a duplicate of this bug. ***
QA Contact: sairuh → petersen
*** Bug 151057 has been marked as a duplicate of this bug. ***
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Severity: normal → critical
I fail to see how this is dataloss...
Severity: critical → normal
Given that 1.0.1 is out, the milestone needs changed.  And, as Boris noted,
giving the wrong extension does not cause dataloss.  It might make the data
harder to read, but not so much so that I would consider the data lost.
Keywords: dataloss
*** Bug 234148 has been marked as a duplicate of this bug. ***
Mass reassign of my non-Firefox bugs to ben_seamonkey@hotmail.com
Assignee: bugs → ben_seamonkey
Status: ASSIGNED → NEW
*** Bug 242644 has been marked as a duplicate of this bug. ***
*** Bug 263864 has been marked as a duplicate of this bug. ***
Please:  Someone who knows should change the Target Milestone.  It can't
possibly be 1.01 since this is still a problem in 1.7.3.  

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.3) Gecko/20040910
(In reply to comment #21)
> *** Bug 263864 has been marked as a duplicate of this bug. ***
Glad this isn't a new bug... err... if you know what I mean.

Boris, the filepicker is a closed component, I guess? I.e I assume no way to
easily get the 'change file type' event? If there is, I don't mind trying to
come up with a solution.
*** Bug 273290 has been marked as a duplicate of this bug. ***
Text file save also have Bug# 321517
Target Milestone: mozilla1.0.1 → ---
Assignee: ben_seamonkey → file-handling
QA Contact: chrispetersen → ian
This problem is confirmed in Firefox 3 RC2 with Windows Xp and Vista
Flags: wanted1.9.1?
Assignee: file-handling → nobody
QA Contact: ian → file-handling
Even if this is necessary for Windows but it's not for Linux.
Because in the most case text files don't have extension in Linux.
This issue still persists in Firefox 3.6.12 on Windows.  If you load up the "Save Page As" dialog select text as the type (causing the filename to get a .txt extension) and save, the next load of the dialog will preselect text as the type but have a .htm extension in the filename (should be .txt for consistancy).
This issue still persists in Firefox 24.0 on Windows.
See Also: → 514494
Product: Core → Firefox
Version: Trunk → unspecified
Why is this bug now limited to Firefox?  Why is it not a Core issue that also impacts SeaMonkey?
Component: File Handling → Widget
Product: Firefox → Core
Whiteboard: [ADT3] → [ADT3][tpi:+]
This bug is still an issue, e.g. on windows 10.

When I want to save a page and change the file filetype to "Plain text", the suffix is correctly changed to "txt".

When I want to save a page again, the filetype is already "Plain text" but the suffix is "html". I would expect it to be "txt" since the filetype already is set to "Plain text".

I.e. the filename has to be adjusted accordingly to the default filetype.

Regards
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 12 duplicates and 11 votes.
:spohl, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(spohl.mozilla.bugs)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(spohl.mozilla.bugs)

No recent reports of this issue. Tentatively closing.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE

(In reply to Stephen A Pohl [:spohl] from comment #39)

No recent reports of this issue. Tentatively closing.

Wrong: Checked with Firefox ESR 102.3.0 (Linux): The bug is still present!

Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
You need to log in before you can comment on or make changes to this bug.