bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

bad display (html codes appearing)

VERIFIED DUPLICATE of bug 26857

Status

()

Core
HTML: Parser
P3
normal
VERIFIED DUPLICATE of bug 26857
19 years ago
19 years ago

People

(Reporter: chagam, Assigned: rickg)

Tracking

({verifyme})

Trunk
x86
Windows 98
verifyme
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
Hi.

I already had problems whith page with netscape Navigator (even 4.7)

1)it seems that the add banner is the source of problem N°1. this banner doesnt
appear on the screen but we can see html code instead. the probleme is
reproductible (just go to http://www.3dfxmania.com to see it)

2)top of all sections (Downloads / The info / The rest...) is badly displayed
corners should be rounded correctly.

Chag

Updated

19 years ago
Assignee: nobody → rickg
Component: Browser-General → Parser
Summary: bad display (html codes appearing) and bad images displaying → bad display (html codes appearing)

Comment 1

19 years ago
Basically, this breaks parsing:

   <SCRIPT LANGUAGE="JavaScript">
     document.write('<SCRIPT SRC="http://www.foo.com/'+args+'"></SCRIPT>');
  </SCRIPT>
--------------------------------------------------------------------^

I'm attaching the full script to this bug for your testing. I'll file the
other problem (tables) separately.

Comment 2

19 years ago
Created attachment 3778 [details]
testcase; the relevant SCRIPT section from the reported page

Comment 3

19 years ago
The other bug is bug #22513 (HTMLTables, karnaze).
(Assignee)

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → INVALID
(Assignee)

Comment 4

19 years ago
We treat this incorrect HTML the same as navigator. If you plan to include
the </SCRIPT> tag in script, you must escape it. Please refer to your javascript
documentation.

Comment 5

19 years ago
Every time I think there some bit of horrendous HTML that maybe shouldn't be
fixed, you go off and fix it. Now you cross me up!

It is certainly invalid HTML, but (I believe) this example shows that Nav4.7
handles it without breaking. (Your option, of course, on what to do :-])

  <html><body>

  Here is var bar<br>

  <SCRIPT LANGUAGE="JavaScript">
  <!--
   var foo = 'var bar = "BAZ"';
   document.write('<SCRIPT>' + foo + '</SCRIPT>');
   document.write('"var bar" has value |' + bar + '| <br>\n');
  // -->
  </SCRIPT>

  That was var bar<br>

  </body></html>
(Assignee)

Updated

19 years ago
Status: RESOLVED → REOPENED
(Assignee)

Updated

19 years ago
Status: REOPENED → ASSIGNED
(Assignee)

Comment 6

19 years ago
The original testcase was invalid, but the new one is legit (since it's in
comments). Reopening. Sigh.
(Assignee)

Updated

19 years ago
Resolution: INVALID → ---

Comment 7

19 years ago
Rick, SCRIPT contents enclosed within a "comment" does not mean anything to the
parser.  As far as the parser is concerned contents within SCRIPT should be
treated as CDATA.  Therefore, I would suggest to invalidate this bug!!
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → INVALID
(Assignee)

Comment 8

19 years ago
Too much eggnog, I think. Harish is right, and this is also invalid HTML. See my
earlier remarks.

Comment 9

19 years ago
rickg, me and harishd (hey, it rhymes) agree that unescaped /SCRIPT inside
SCRIPT is undeniably invalid HTML, and, yes, comments are irrelevant within
CDATA. It's also, I'm sure, a very painful pattern to parse.

However, Nav4.6/4.7 on win32 "forgives" this abuse (and it's probably XP for
4.0n+, at least).

So, at risk of your goodwill, I am going to REOPEN this bug just to bring the
the 4.xP point to your attention (but immediately INVALID this bug again if
I need a whack with the clue stick -- that is quite OK with me [I'm not the
original bug reporter anyways]).

This is only a backwards-compatibility issue. Unfortunately, most people code
to what works, and, really unfortunately, it's ad banners that may be the
biggest abusers of this "forgiveness": i.e., I think this will be reported "as
a bug" quite a few times as you move into beta.

Updated

19 years ago
Status: RESOLVED → REOPENED

Comment 10

19 years ago
Doh! Didn't hit the REOPEN radio last time ...
(Assignee)

Updated

19 years ago
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: INVALID → REMIND
(Assignee)

Comment 11

19 years ago
Ok -- I'll leave it in the remind pile, only because you've been a big help to
us. I'll think about it later under the category "ways to improve dealing with
crappy html.".  : )
There is another bug covering this issue now...
Status: RESOLVED → REOPENED
Resolution: REMIND → ---
...and this is a duplicate.

*** This bug has been marked as a duplicate of 26857 ***
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago19 years ago
Keywords: verifyme
Resolution: --- → DUPLICATE

Comment 14

19 years ago
verified dup
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.