95754 - Should strip spaces from ends of CDATA attributes

Status: VERIFIED DUPLICATE of bug 87894

(Core :: DOM: HTML Parser, defect, P3)

Description

[jim_nance]

This page does not layout correctly.  Parts of it are just missing.  It works

Comment 1

[jim_nance]

Mozilla decided that I wanted to submit that last piece all by itself.  I guess
that is another bug :-)  Anyway I was saying that it renders fine with Netscape
4.77.  I tried with mozilla 0.9.3 and with last nights build and both of them
fail to render the page.

Comment 2

[Aaron Kaluszka]

Hmm Composer pulls it in better.. you can look at its "fixed" source and see the
problems.  I think that all those
<img src="(newline)
(spaces)imagename" ....>and
<a href="(newline)
(spaces)link" ....>
are really screwing things up.
I don't know how to classify this though, INVALID or not..
I just don't understand why it wasn't written
<img(newline)
(spaces)src="imagename" ....>
and
<a(newline)
href="link" ....>

Anyway this is why the images aren't coming up.. I guess this is affecting
alignment too which may be actually be a bug..

Comment 3

[Andreas M. "Clarence" Schneider]

This is probably evangelism, see bug 42287.

Comment 4

[karnaze (gone)]

Reassigning to parser.

Comment 5

[Andreas M. "Clarence" Schneider]

Actually, HTML 4.01 (6.2) says this about CDATA attributes:

| User agents may ignore leading and trailing white space in CDATA attribute
| values (e.g., "   myval   " may be interpreted as "myval"). Authors should
| not declare attribute values with leading or trailing white space.

Because we're already ignoring '\t', '\n', '\r' and '\b', I think we should
ignore spaces too. This would be a simple 2-line change at
http://lxr.mozilla.org/seamonkey/source/content/html/document/src/nsHTMLContentSink.cpp#710

This seems to be an issue for quite a few real web pages.
I haven't duped this to bug 42287, because that is only about non-CDATA
attributes. But it's basically the same bug.

Comment 6

[Andreas M. "Clarence" Schneider]

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

Comment 7

[Andreas M. "Clarence" Schneider]

Attachment: simple patch

Comment 8

[Andreas M. "Clarence" Schneider]

The patch is an easy way to fix this, but it would be even better to do it in
the tokenizer and remove HTMLContentSink::GetAttributeValueAt() altogether,
because for XHTML this applies only to non-CDATA attributes, and even then
a tab resulting from "&x9;" should not be stripped. Only the tokenizer knows
if a tab was once a character entity.

Comment 9

[Christopher Hoess (gone)]

<broken_record>Perhaps we should consider this a quirks-mode-only change?</broken_record>Rationale: as you point out, XML, unlike HTML, does not allow this bit of normalization in non-CDATA attributes.  (i.e., all attributes, for our non-validating-XML-parser purposes).  People shouldn't have their pages breaking when they convert from standards mode into XML.  (Indeed, I wonder if such ambiguity in whitespace processing contravenes the SGML spec...but beating that horse is Arjun Ray's job.)

Comment 10

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 11

[rbs]

See also bug 98107
which was fixed with this checkin:
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsObjectFrame.cpp&root=/cvsroot&subdir=mozilla/layout/html/base/src&command=DIFF_FRAMESET&rev1=1.254&rev2=1.255

Comment 12

[rbs]

Cc:ing bratell since LXR gives him the blame for that code which was checked in 
to fix bug 83945.

Comment 13

[Daniel Bratell]

I just moved the functionality to a faster tokenizer. The tokenizer still parses
the data the same way. You may want to look at the "blame" for the code I replaced.

Comment 14

[harishd]

--> 0.9.6

Comment 15

[harishd]

Moving lower priority bugs to m1.0.

Comment 16

[Christopher Hoess (gone)]

*** This bug has been marked as a duplicate of 87894 ***

Comment 17

[Moied]

Verified duplicate of 87894