Closed Bug 2701 Opened 26 years ago Closed 25 years ago

{sink} Style tag adding table row

Categories

(Core :: CSS Parsing and Computation, defect, P2)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: michael.j.lowe, Assigned: vidur)

References

Details

Attachments

(1 file)

The style tag in this html is causing an extra row to be added to the first
table which duplicates the first row.

<HTML>
<HEAD>
</HEAD>
<BODY>

<TABLE BORDER=2>
<TR>
<TD ROWSPAN=2>
A
</TD>
</TR>
</TABLE>

<BR>

<TABLE BORDER=2>
<TR><TD>
B
<STYLE TYPE="text/css">
 <!--
 A:link { text-decoration: none; }
 A:visited { text-decoration: none; }
 :active { text-decoration: none; }
 -->
</STYLE>
</TD></TR>
</TABLE>

</BODY>
</HTML>
Assignee: peterl → rickg
Component: Style System → Parser
I suspect this is a parser issue. Note to submitter: <STYLE> tags are completely
illegal outside the <HEAD> element, under a strict DTD we would reject it
completely.
Status: NEW → ASSIGNED
Setting all current Open/Normal to M4.
Assignee: rickg → buster
Status: ASSIGNED → NEW
Hey! Wait a second. Did you even try dumping the content model?
The real problem appears to be in tables. The content model I'm creating is
valid (as far as I can tell). But the top table has a rowspan of 2 which seems
to be duplicating the first cell.
The HTML below shows that this bug is not necessarily table related.
The test case will display two instances of the paragraph.

Tested viewer.exe win95 non-debug

  Jan15  -- ONE paragraph (but the border is red (??))
  Jan25  -- _TWO_ paragraphs (sorry. no other-dated copies to test)
  Feb03  -- TWO paragraphs
  Feb10  -- TWO paragraphs

I put in a bug (#3092) that is a variation on this bug, so I am marking that
one as a duplicate of this one. (And yes, I agree that STYLE is illegal in
the BODY).

  ==============================
<html><head>
<style>
P   {border: solid blue 1px}
</style>
</head>

<body>

  <P> is this 'P' written once or twice?
      is this 'P' bordered in blue or red?
  </P>

  <style>
    P   {border: solid red 1px}
  </style>

</body>
</html>
*** Bug 3092 has been marked as a duplicate of this bug. ***
Assignee: buster → karnaze
sounds like problems with Chris' new table frame creation code.
Assignee: karnaze → rickg
This is NOT a table problem. The example below has the same symptoms and uses
<UL> and <LI> instead of tables. Even though the content model looks ok, the
<STYLE> is causing redundant calls to nsCSSFrameConstructor::ContentAppended
which creates duplicate frames.

<UL>
<LI>foo
</UL>
<BR>

<UL>
<STYLE TYPE="text/css">
 <!--
 A:link { text-decoration: none; }
 A:visited { text-decoration: none; }
 :active { text-decoration: none; }
 -->
</STYLE>
<LI>bar
</UL>
Assignee: rickg → troy
Troy -- this appears to be a frame construction problem. The content model is
wellformed. Please take a look.
Assignee: troy → karnaze
Component: Parser → HTMLTables
Assignee: karnaze → troy
Assignee: troy → peterl
Component: HTMLTables → Style System
Okay, back to Peter to see what light he can shed on the problem. The key seems
to be the STYLE tag mid way through the document.

I don't know what the resulting flow of control is, but the frame construction
code relies on the caller of ContentAppended() to indicate the index of the new
content. It that index is wrong, there will be a problem
Assignee: peterl → kipp
The problem here is most likely in either the content sink or the parser. The
sink is adding the style element to the head, but notifying the table that a
content node was appended...
Status: NEW → ASSIGNED
Summary: Style tag adding table row → {sink} Style tag adding table row
*** Bug 5526 has been marked as a duplicate of this bug. ***
From bug 5526:

Created an attachment (id=66)
Snapshot of http://seattle.sidewalk.com/

This page should be checked once the bug is fixed.
Assignee: kipp → peterl
Status: ASSIGNED → NEW
Taking this bug. The problem is actually the fact that the content sink is
adding content to the document without notifting the document. When the style
sheet gets applied, all content is found and layed out, then the sink notifies
about content that was previously appended and frames get generated again.
*** Bug 8477 has been marked as a duplicate of this bug. ***
Target Milestone: M15 → M9
*** Bug 10312 has been marked as a duplicate of this bug. ***
Target Milestone: M9 → M10
Moving all content sink issues to M14.
Make that M14.
Thanks for taking this Vidur. Many of these are likely dups. I haven't marked
them as such to make sure I had the testcases handy...
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Fixed with sink changes on 10/26/1999.
Status: RESOLVED → VERIFIED
Using 11/16 build, verified fixed
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: