Closed Bug 177122 Opened 22 years ago Closed 22 years ago

2 CR are inserted for every CR/LF inside a <script> tag when saving the .html

Categories

(SeaMonkey :: Composer, defect)

Product:
SeaMonkey
Component:
Composer
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 159615

People

(Reporter: oliver, Assigned: cmanske)

Details

Attachments

(1 file)

working test case
333 bytes, text/html
Details 
Mozilla 1.2b Build ID: 2002101612

If you have and .html file with a <script> tag and edit it in composer,
composer adds 2 CR(Carriage Return) for every CR/LF caracters that are
inside the <script> tag when you save the .html file.

Example (showing the invisible CR/LF caracters):
This code:
<script type="text/javascript" language="JavaScript">CR/LF
<--CR/LF
function("param");CR/LF
//-->CR/LF
</script>CR/LF

Is changed to this code when saving:
<script type="text/javascript" language="JavaScript">CRCRCR/LF
<--CR/LF
function("param");CRCRCR/LF
//-->CRCRCR/LF
</script>CR/LF

To use the example:
1. copy the example code inside an .html file and save it using an
   standard text editor(vi, notepad.exe)
2. Open the file in Composer, change something(the title for example)
   and save the file.
3. Then, open again the .html file inside notepad.exe or and hex editor,
   you will note the double CR caracters
Attached file working test case — 
To use this test case:
1. open this file in composer
2. delete the first "t" from the word "test"
3. save the html file
4. open the file in an hex editor or notepad.exe
This is very annoying since it also adds the extra CR/LF when you back and forth
between normal mode and HTML Source mode. There's lots of CR/LF "polution" in the
<head> region.
Akkana: could you please triage this? Are there existing bugs about CR/LF problems
that this can be duped to?
Assignee: syd → akkana
CRs should never get inside the DOM.  The parser should translate CRLF to LF,
since the DOM newline character is simply an LF.  Is that not happening for JS?
I don't know about the DOM.
But this bug happens when you create a .html in an editor in WinXP
and then edit it in Mozilla Composer.
It also happend if you are creating a .html directly in Composer,
but this test case I made in notepad.exe and then edited in Composer.

Download the attachment #104375 [details], edit and save in Composer. You will
see the extra CR added.
Also, the bug is progresive. The first time you save, you got 2 extra CR.
The second time you edit, you get 3 CR and etc, etc.

You have to quit Composer and the open it again to get more than 2 CR.

This only happend inside the <script> tag when it is inside the <body> tag.



Oh, I didn't notice Charley hadn't cc'ed himself and didn't see my previous comment.

This bug needs someone on Windows to find out how those CRs are getting into the
DOM (assuming they are).  They shouldn't be there.  And no, I don't know of any
existing bugs on this issue.
Assignee: akkana → cmanske
similar: bug 176866
Akkana, it seems to the dupe of bug 159615. Patch for that one resolves this 
too. Also it can be explained on the same basis i.e. script tag is having CRLF 
which enter the DOM. Now when the DOM passes through 
nsHTMLContentSerializer.cpp, LF is replaced by CRLF, the line break for 
windows. This changes CRLF->CRCRLF. I could not check where the third CR is 
entering but removing these CR characters definitely resolves the problem.

I'm marking it as dupe of 159615. If I'm missing something, please feel free to 
modify it.

*** This bug has been marked as a duplicate of 159615 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Well,
I made a test case in bug #46227 and the resoluction was to fix the blank
lines in the body and then create a new bug for the HEAD issue.

I followed that sugestion and now I created this bug for the <script> issue.

Please note that in the <HEAD> issue, the caracters CR/LF are added 
and here only CRCR caracters are added. This you can verify with my test
case, it is attached to the bug.

I will reopen this bug because:
Bug #159615: deals only with CR/LF caracters only in the HEAD tag
Bug #46227: deals only with CD/LF caracters only inside the BODY tag and outside
any SCRIPT tag.
Bug #177122: deals only with CRCR caracters only inside the SCRIPT tag.

If you want to generalize bug #159615 then close this bug again. But I don't
think to generalize a bug is good.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Also,
the bug is reproducible when selecting:
View->Page Source
Try viewing the attachment #104375 [details], you will notice the
extra CR, then save the attachment to a file a open it
in a text editor(notepad), the extra CR are gone.

It seems that a bugged function is called when saving the .html
in composer and when viewing the source of a page in Navigator.

Oliver, please see http://bugzilla.mozilla.org/show_bug.cgi?id=159615#c15. 
Probably that would remove the confusion between both the bug descriptions.

So marking it a dupe again.

*** This bug has been marked as a duplicate of 159615 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → DUPLICATE
mmm,
I don't know man, we have here to situations:
- adding CRCR when saving(not opening) an html in composer
- adding CDCR when viewing the source of an html from navigator
Are you sure this is a dupe of bug #159615?

Also, what happend with bug #145196? Why don't you make
bug #159615 a dupe of bug #145196?

any way, is there a reference on how to make dupes on bugs?
Because I have found many cases where bug are generalized.

Here the basis for dupe is the "fix". With this view, we find 159615 to be a 
superset of this one whereas for bug#145196, cause & fix seems to be different 
altogether. Isn't it?
As I see,
bug #159615 contains a detailed description of the STYLE bug
bug #177122 contains a detailed description of the SCRIPT bug

Also, please delete attachment #103725 [details] since it is outdated 
because of the summary change in bug #159615
The attachment #104625 [details] should be used now.

verified.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: