166597 - ScanDocStructure doesn't handle auto-closing tags

Status: RESOLVED WONTFIX

(Core :: DOM: HTML Parser, defect)

Description

[João S. O. Bueno]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826

When changing an inline html element, (e.g. strong, em, spam, font), to 
block, through  CSS display porperty, the PARAGRAPH boxes inside said element
behave erractly depending on the first paragrpah inside the element
being terminated with a </p> tag, or not.

If the paragraph is not terminated with </p> CSS elements like borders and
background are created in a per paragraph, and for an extra top, otherwise
hidden, anonymous BOX.

Otherwise,(terminating </p> in first para) the whole element is displayed inside
a single CSS modified BOX, as would be expected.

This may be related to BUG #166461 -- which is also triggered by a 
missing </p> tag.

Affected HTML elements I teste were: em, font, span, strong, i, b.

the DIV element, being naturally a BLOCK element is not affected.

Reproducible: Always

Steps to Reproduce:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<p>
There should not be an empty border bellow this line.

<em style="border: solid 5px red; display: block;">
<p>
This line and the next should be inside a single border. It wasn't supposed to be
a separate box above.


<p>
This should be in the same frame as the pargraph above.


</em>
<p>
Case two:
</p>
<em style="border: solid 5px red; display: block;">
<p>
This line and the next should be inside a single border. It wasn't supposed to be
a separate box above.
</p>


<p>
This should be in the same frame as the paragraph above.


</em>
Actual Results:  
Three separated bordered boxes appeared

Expected Results:  
Display all text inside a single border.
(It will do if first para inside <em> is terminated by </p>,
or if instead of a modified inline element it is a naturall block element such
as div )

Comment 1

[Mats Palmgren (inactive)]

Attachment: Testcase (markup from the description)

Comment 2

[Christopher Hoess (gone)]

This looks like the results of residual style. There may already be a bug on
this (I remember one about B tags with an ID on them getting multiplied in this
manner); 
for now, it's best to avoid taking advantage of OMITTAG, which tends to set off
all the tag-soup-handling features in the parser.

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

The parser will never get your examples right, it has no way of know if you mean </p></em>. I could try to make it handle <em><p><p></p></em> if it's deemed worth it (probably not).

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

I don't think this is worth fixing. Even fixing ScanDocStructure to not mess up this case would not be a guarantee that we'd get this right, since a <script> in the middle of the <em>...</em> or even a packet boundary would "regress" our behavior.