166866 - HTML escape chars in textarea have confusing behavior.

Status: RESOLVED DUPLICATE of bug 154882

(Core :: DOM: HTML Parser, defect)

Description

[Sam Rowe]

HTML escape chars like " are usually "translated" by the browser, when
present in <textarea>. However, using today's build, if the escape-chars are in
a tag, in quotes, they are not translated.

I write an application which "double escapes" html special characters becuase of
the way most(all?) browsers handle escape chars in textarea. It makes &quot;
into &amp;quot; so that the browser will render it as &quot; in the text area. 

&lt;li&gt; will render just fine, but:
<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=78676" title="[Bug 78676]
selection inside a single &lt;li&gt; shouldn't include bullet">Yea!</a>

will render as :

<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=78676" title="[Bug 78676]
selection inside a single &amp;lt;li&amp;gt; shouldn't include bullet">Yea!</a>

in a textarea

Comment 1

[Boris Zbarsky [:bzbarsky]]

This is parser.  Could you attach a small HTML file demonstrating the problem
using http://bugzilla.mozilla.org/attachment.cgi?bugid=166866&action=enter ?

Comment 2

[Sam Rowe]

Attachment: HTML example

Comment 3

[Sam Rowe]

I guess I should also point out that when you File: Save As the attachment, the
saved source actually has < in it, which differs from what View
Source shows (and the way the file really is.)

Comment 4

[Russ Southern]

Bug #167616 may be related to this issue...(?)

Comment 5

[Christopher Hoess (gone)]

I'm not really sure what the correct behavior should be here; <textarea> isn't
allowed to have content other that text, and I imagine sticking that <a> element
in there is confusing the parser.

Comment 6

[Christopher Hoess (gone)]

Coming back to this...yes, your problem is that you're putting "<a ..." into the
textarea, which isn't valid. Change that to "&lt;a ..." and the parsing will
work fine. Resolving bug as INVALID.

Comment 7

[Sam Rowe]

They said the same thing about Bug 133044 at first. This is a compatibility
issue. Right or wrong, lots and lots and lots of people use <textarea> to edit
web pages and other browsers don't mangle HTML entities. Mozilla shouldn't either. 

Comment 8

[Sam Rowe]

Is this bug still unconfirmed?

Comment 9

[Edward Bilodeau]

I've noticed a similar problem using Mozilla 1.2 with Blogger
(http://www.blogger.com). When I try to edit my weblog template with Mozilla,
all of the attributes in the anchor tags are stipped out. For example:

<a href="...">foobar</a>

becomes

<a>foobar</a>

Now, if I do a viewsource on the page with the textarea, all of the data is there:

<a href="...">foobar</a>

It's just not being displayed by Mozilla.

Note that I only have this problem with that one textarea on the Blogger site.
There are other textareas on the Blogger site that don't cause any problems.

Comment 10

[Chris Casciano]

Attachment: updated testcase

testcase showing parser is breaking on a tag opening

Comment 11

[Chris Casciano]

Confirming All/All off 1.3b/OS X based on my updated testcase.

The parser is indeed choking on the A tag... yes this is all invalid code... but
I think the parser should be consistant about parsing entities between the 3
textareas in the updated testcase

Comment 12

[Hixie (not reading bugmail)]

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

Comment 13

[Hixie (not reading bugmail)]

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