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

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.

*** 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.

mebbe not dogfood, but this does seem like catfood.

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.

renominating dogfood - this makes platform-to-platform patching VERY difficult...

mass move, v2. qa to me.

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.

*** Bug 89251 has been marked as a duplicate of this bug. ***

*** 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.

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

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

Why is this bug now limited to Firefox? Why is it not a Core issue that also impacts SeaMonkey?