Open Bug 38121 Opened 24 years ago Updated 2 years ago

"save as" should convert line breaks depending on platform

Categories

(Firefox :: File Handling, defect, P4)

Product:
Firefox
Component:
File Handling
Type:
defect

Tracking

()

People

(Reporter: jruderman, Unassigned)

References

Details

(Keywords: helpwanted) 

Windows:
1. Load http://www.w3.org/Style/CSS/Test/current/sec5525.htm
2. Save to desktop using mozilla
3. Open with notepad

Actual Result: get boxes for line breaks, so page is unreadable

Hoped-for result: line breaks show up in notepad as line breaks

Netscape 4x gives the hoped-for result; IE doesn't for "save as" but does 
for "view source".
->law
Assignee: gagan → law
Target Milestone: --- → Future
Status: NEW → ASSIGNED
Keywords: dogfood, helpwanted
I can belive this is a nice fix, but it can't be the blocker that precludes
using it as dogfood.  Marking dogfood-minus.  Adjusting priority to P4.
Priority: P3 → P4
Whiteboard: [dogfood-]
*** Bug 40198 has been marked as a duplicate of this bug. ***
The output system should do correct linebreak conversion. cc akkana

The output system does do linebreak conversion (controlled by flags), but
browser "save as" doesn't go through the output system, since it's just
reloading the page from netlib and copying the result to disk rather than
reading it out of the DOM.
Keywords: nsdogfood-
Keywords: nsdogfood
mebbe not dogfood, but this does seem like catfood.
Keywords: nsCatFood
If we don't fix this, Mac users can't use SimpleText to open up saved HTML files, 
and many of them will get confused.

This bug makes it hard for developers to apply patches saved from bugzilla 
attachments on Windows and Unix. Fixing this (which should be pretty easy) would 
be a big win.

Could this be an option? iirc netscape4 managed to mangle certain line breaks 
on certain platforms.  Windows Common Dialogs are extenisble (and I recently 
came across a microsoft example - non office), XP File Picker could certainly 
get this, and either Nav Services can do this, or there's some way to ask the 
user on macos...
Rather than leave it to the user, maybe we can deduce whether to convert these
types based on the mime type?  I don't think 4.x had options for the user to
control this, did it?

Is it simply a matter of filtering/converting the linebreaks for text/html and
text/plain?  Is the logic the same for all platforms (i.e., always convert
non-native to the platform native)?  Or is it more complicated, like: On Mac,
always convert to Mac convention; on Windows, convert Mac to Windows, but leave
Unix alone; on Unix, it doesn't matter?
As long as we correctly recognize the original formatting convention my 
concerns are probably void.
My guess is that line breaks (CR, LF, CRLF, and maybe LFCR) in text/* and 
application/x-javascript would always be converted to platform line breaks, and 
other files (which are likely to be binaries) would be saved without conversion.
What jesse said.

nav triage: does not impact a high percentage of our users. hence nsCatfood-. 
please renominate for nsdogfood if it impacts day to day developer usage.
Keywords: nsCatFood → nsbeta1-, nsCatFood-
renominating dogfood - this makes platform-to-platform patching VERY difficult...
Keywords: nsdogfood- → nsdogfood
Keywords: nsdogfood → nsdogfood+
mass move, v2.
qa to me.
QA Contact: tever → benc
Is this Networking or XP Apps? The dupe said XP apps.

re-nscatfood, this probably affects everyone that wants to use Save As. I
stopped using Save As because of this problem.
Keywords: nsCatFood- → nsCatFood
*** Bug 89251 has been marked as a duplicate of this bug. ***
Component: Networking → File Handling
*** Bug 109341 has been marked as a duplicate of this bug. ***
Works for "web page, complete", but that option is unlikely to be selected by
someone who wants to edit the source.

At plain-text documents such as http://www.tuatha.org/~mpk/words/drunken.txt,
this is a bug (bordering on dataloss) and not an rfe.
Severity: enhancement → normal
Summary: RFE: "save as" should convert line breaks depending on platform → "save as" should convert line breaks depending on platform
Whiteboard: [dogfood-]
Should this conversion happen for "save link as"?  Or just for "save page as"? 
Should it happen only for text/plain?  Or also for text/html and such?  What do
we do with two-byte encodings such as UTF-16 or UCS-2?
*** Bug 146614 has been marked as a duplicate of this bug. ***
*** Bug 147405 has been marked as a duplicate of this bug. ***
As another note, consider a binary file sent as text/plain by the server.  The
user clicks the link, sees garbage, knows they want to save the file, goes to
"File > Save As", then what?
I think if the user displays the file in the browser window it should convert
the linebreaks as default.

if the user rightclicks -> save link as then there should be a tick box to
convert  line breaks.

if the file extension is recognised as text/plain and the file was sent as
text/plain this "convert tick box" should be on.  If the extension is not
recognised or the file is not sent as text/plain this "convert tick box" should
be OFF.

Either way the user can change this if they decide they do or dont want to
convert line breaks.

This seems the best solution IMO.

JG
> if the file extension is recognised as text/plain 

Please let's not do this if it's at all avoidable.  Extensions and content have 
nothing to do with each other, pretty much...  I want my .diff text/plain files 
treated exactly like my .txt text/plain files, thank you.  At least then I get 
predictable behavior...
> ------- Additional Comments From bzbarsky@mit.edu  2002-05-27 19:41 -------
> 
>>if the file extension is recognised as text/plain 
> 
> 
> Please let's not do this if it's at all avoidable.  Extensions and content have 
> nothing to do with each other, pretty much...  I want my .diff text/plain files 
> treated exactly like my .txt text/plain files, thank you.  At least then I get 
> predictable behavior...

If there are 2 conditions before the "convert line endings checkbox" is ticked
(and the user can deselect the checkbox) I think this is fine.


Perhaps the "convert line endings checkbox" in the save as dialog should always
be OFF by default then for those users who wish to use this translation of
linefeeds when the conditions match they can enable it in prefs.js etc

I'm only sugesting enabling it IF and only IF contenttype is text/plain and file
extension is .txt .c etc (but if this is an advanced prefs.js feature I dont
think there should be a problem)

JG
QA Contact: benc → sairuh
QA Contact: sairuh → petersen
My employer's web application stumbles because of this problem. I would like to
help move this along. If I want to fix it, how do I coordinate?
Well.. since no one is working on it right now, you could just take the bug... ;)

Be aware that doing this without screwing up people's expectation that saving
binaries served as text/plain will not munge them is somewhat difficult...
Yes, and I'm reminded of the joke about how God was able to create the world in 
six days.  (He didn't have an installed base.)

How important is such "bug compatibility"?  We all agree, I assume, that for the 
server to send a binary file claiming it's text is a bug, don't we?  How do the 
other browsers handle this?  Why does Mozilla have to support this use case?

We agree it's a bug.  Other browsers handle it by:

NS4:  exactly like Mozilla does now
IE:  Ignores server type to start with and just pops up a download dialog
Others: no idea

It's pretty important, because it's the only way to save files from many
misconfigured servers.... in IE the download dialog comes up, but Mozilla
renders the file as text.  At that point the only way to save it is to do "save as".

One possibility is to only do the conversion if the type in the filepicker is
selected as "Text file".  If the type selected in the filepicker is "*.*" then
we would not convert.....
Re comment 10: On Mac OS X, please use Unix linefeeds. Everything else will be
screwed up in shell apps, although GUI apps handle them all.
> NS4:  exactly like Mozilla does now

I thought at least some NS4/win versions had the bug where they'd
newline-convert binaries?  That's the reason I always see for why people take a
single Palm .prc, or a single windows .exe, and package it as a zip archive on a
download site (apparently .zip isn't newline converted, but exe and prc are).

I've also see lots of windows users claim this is why they switched from NS4 to
IE.  Let's try not to break it in mozilla.

I like the idea of having a checkbox in the download dialog, so the user can
override broken servers when necessary.  Don't know how hard it would be to
implement, though, with our platform-specific download dialogs.
*** Bug 211130 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.3) Gecko/20040910

This is still a problem.  Another example:  
1.  Go to <http://www.rossde.com/PGP/pgp_keysign.html>.
2.  Near the bottom of the page, select the link for "(using this link)", which
is <http://www.rossde.com/PGP/pgp_keysign_reg.txt>.  The text displays correctly
in the browser window.  
3.  Return to <http://www.rossde.com/PGP/pgp_keysign.html>.  
4.  On the link for "(using this link)", right-click.  Select "Save Link Target
As" from the pull-down menu.  Save the file as text.  
5.  View the saved file in an ASCII viewer.  Lines run together.  Line breaks
(should be CR/LF, hex 0d0a) are black boxes (CR/CR, hex 0a0a).  
> This is still a problem.

We know.  If it were not, this bug would be resolved.
> One possibility is to only do the conversion if the type in the filepicker is
> selected as "Text file".  If the type selected in the filepicker is "*.*" then
> we would not convert.....

Why not give the user a choice between converting line separators and
saving the file as retrieved?

Daniel
Assignee: law → nobody
Status: ASSIGNED → NEW
QA Contact: chrispetersen → file-handling
Product: Core → Firefox
Target Milestone: Future → ---
Version: Trunk → unspecified
Why is this bug now limited to Firefox?  Why is it not a Core issue that also impacts SeaMonkey?
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 6 duplicates.
:Gijs, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(gijskruitbosch+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?(gijskruitbosch+bugs)
You need to log in before you can comment on or make changes to this bug.