Closed Bug 257202 Opened 20 years ago Closed 19 years ago

Composer Corrupts Pasted HTML Code

Categories

(SeaMonkey :: Composer, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: vgendler, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803

Pasted the valid HTML code in the HTML Source Tab and switched to the Preview Tab.
The pasted HTML code got corrupted.
Checked with the latest versions of Macromedia Homesite+, Macromedia
Dreamweaver, Microsoft FrontPage 2003 and everything was fine.

Reproducible: Always
Steps to Reproduce:
1. Paste the next code into Source:
<html>
<body>

<h1 align="center">A Sample Article</h1>

<h2>The First Major Section


  </h2>
<p>This section will introduce a subsection.</p>
<h3>The Subsection Heading

     </h3>
<p>This is the text of the subsection.
       </p>

</body>
</html>
2. Switch to any other composer Tab and the Source Tab again


Actual Results:  
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="content-type">
<title></title>
</head>
<body>
<br>
</body>
</html>

Expected Results:  
<html>
<body>

<h1 align="center">A Sample Article</h1>

<h2>The First Major Section


  </h2>
<p>This section will introduce a subsection.</p>
<h3>The Subsection Heading

     </h3>
<p>This is the text of the subsection.
       </p>

</body>
</html>
Your code to paste and your expected results have no <head>...</head> section at
all. No <title> either. So that was not really valid HTML markup code to begin with.

With your steps to reproduce, these are the actual results I get with Mozilla
Composer 1.8a3 build 2004090105 under XP Pro SP2:

<html>
<head>
</head>
<body>
<h1 align="center">A Sample Article</h1>
<h2>The First Major Section </h2>
<p>This section will introduce a subsection.</p>
<h3>The Subsection Heading </h3>
<p>This is the text of the subsection. </p>
</body>
</html>

and the text is rendered accordingly in Preview editing mode. I think Composer
should have created an empty <title></title> node.


Other steps to reproduce:
-------------------------
- Copy this code:
<h1 align="center">A Sample Article</h1>
<h2>The First Major Section </h2>
<p>This section will introduce a subsection.</p>
<h3>The Subsection Heading </h3>
<p>This is the text of the subsection. </p>

into a blank Composer document (overwrite the <br> inside the <body>...</body>
of the blank Composer document) in HTML source editing mode.
Then switch to Preview editing mode.

Actual results in Composer HTML source editing mode of Mozilla 1.8a3 build
2004090105 (with Reformat HTML source checked):
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="content-type">
<title></title>
</head>
<body>
<h1 align="center">A Sample Article</h1>
<h2>The First Major Section </h2>
<p>This section will introduce a subsection.</p>
<h3>The Subsection Heading </h3>
<p>This is the text of the subsection. </p>
</body>
</html>

Expected results: see above.

Can you try these steps and report back in here? Thanks.
In reply to  ------- Additional Comment #1 From drunclear@hotmail.com 
2004-09-01 16:38 PDT
You wrote: "Your code to paste and your expected results have no
<head>...</head> section at
all".
Correct. But is not a mandatory HTML tag.
You wrote: "No <title> either".
Of course, because it must be nested in <head></head>.

You wrote: "Can you try these steps and report back in here?".
I did somewhat different.
1. I pasted the code indicated in the original post into Macromedia Homesite+ and
saved it.

2. I opened the saved file in Mozilla. It opens fine

3. Here is that HTML source viewed in Mozilla:
========================================
<html>
<body>

<h1 align="center">A Sample Article</h1>

<h2>The First Major Section


  </h2>
<p>This section will introduce a subsection.</p>
<h3>The Subsection Heading

     </h3>
<p>This is the text of the subsection.
       </p>

</body>
</html>
========================================

4. As we all know Mozilla fully supports the HTML standard that is the above
code is perfectly valid HTML code.

5. If so then it would be no good to follow your suggestion: "Composer
should have created an empty <title></title> node". No reason to generate
excessive code if the code is fine especially taking into account that HomeSite+
and several other popular HTML editors do not do this.

6. All these were tested in Mozilla 1.7.2.

Thanks.
err, title is a required tag. it may live in an implied head, but it is required.
Reply to  ------- Additional Comment #3 From timeless@myrealbox.com (working) 
2004-09-01 17:30 PDT  

You wrote "err, title is a required tag. it may live in an implied head, but it
is required".
OK, but in this case the Mozilla's claim that their browser is 100% HTML
compliant is not true.
eh, how so?
lastly, where does "Mozilla" claim to be 100% HTML compliant?
In reply to  ------- Additional Comment #6 From timeless@myrealbox.com (working)
 2004-09-01

"where does "Mozilla" claim to be 100% HTML compliant?"

I do not remember, I think in documentation.

But what I remember for sure that on some bugs I reported earlier the answer was
that "it is not standard HTML". Which means ... that clam.
Your summary says that Composer corrupts HTML code: I disagree. I say it
improved the bad code pasted in the particular case you've submitted. I did not
get exactly the same results as you did with your very own steps to reproduce:
everything I got and said is reproducible by anyone.

A valid HTML document starts with a valid doctype declaration, it requires a
<head> section and <title> is mandatory. You're pasting a whole invalid HTML
document while the steps I recommended was to paste a document fragment (body
content).

You go now as far as to insist that "the above code is perfectly valid HTML
code." <shrug> I don't know what to tell you. I invited you to try steps which I
thought IMO (and still believe) would be more reasonable and more expectable to
see from web authors: you declined without explaining why.

In the final analysis, browsers, editors, DOM inspector, DOM parsers, web-aware
devices and sofwares deal with real documents and real HTML 4.01 specifications
regardless of how many transformations they went through. Some will even crash
when code is insufficient and "not excessive" like you say (e.g. MSIE 6 SP1
crashes when meeting <input type>).
You don't seem to understand what browser internal error correction mechanisms
do and why web authors (and HTML editor softwares) - now and later - should NOT
rely on these to render their documents and/or HTML code.

I don't have Macromedia Homesite+. What Macromedia Homesite+ does (laxism,
tolerance to invalid code) should not dictate what Composer should do; your
argument is based on rendering of document (not even saved on a web server) in 1
single visual browser, not on W3C HTML 4.01 specs. You say "several other
popular HTML editors do not do this": Front Page 2000 will add a <head> section
to your code when it loads your invalid HTML document. So even that claim could
be discussed.

You chose Version: trunk btw, not 1.7 branch.

I am not module owner, so someone else will have to make a final call on your
claims and demands. As far as I'm concerned, Composer should compensate and
correct bad code as much as it can within its capabilities to prevent
interoperability, accessibility problems and other kinds of problems. Missing
the whole <head> section is not a trivial node missing. I recommend 

WONTFIX
Very Good! I submitted and that is it.

It is up to you guys. You want something impractical - you already have it.


(In reply to comment #8)
> Your summary says that Composer corrupts HTML code: I disagree. I say it
> improved the bad code pasted in the particular case you've submitted.
> 
=======================================================
HTML is bad by definition this is why W3C will not issue
other versions, this is why we have XHTML.
Nobody asked to "improve" code.
=======================================================
> I don't have Macromedia Homesite+. What Macromedia Homesite+ does (laxism,
> tolerance to invalid code) should not dictate what Composer should do; your
> argument is based on rendering of document (not even saved on a web server) in 1
> single visual browser, not on W3C HTML 4.01 specs. You say "several other
> popular HTML editors do not do this": Front Page 2000 will add a <head> section
> to your code when it loads your invalid HTML document. So even that claim could
> be discussed.
=======================================================
But FrontPage 2003 DOES NOT ADD ANYTHING
and Macromedia Dreamweaver 2004 also DOES NOT ADD ANYTHING.
T have checked not only in their views but also in the saved html files.
Both are very RESPECTABLE tools  
=======================================================


Product: Browser → Seamonkey
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
INVALID based on discussion.

Gerv
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.