56245 - Table cell wrongly located

Status: VERIFIED FIXED

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

Description

[Frederic Crozat]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-21mdk i686; en-US; m18) Gecko/20001011
BuildID:    2000101108

Page rendering is completly broken

Reproducible: Always
Steps to Reproduce:
Load URL and compare with Netscape 4.75


Actual Results:  Cells called "Programmes Télé" and "Articles" are displayed
below "Salles de Cinema"

Expected Results:  Theses cells should be on the right of "Salles de Cinema"
(Hard to explain, check correct rendering using Netscape 4)

Comment 1

[James Lariviere]

Reporter:

Can you simplify your sample url please.  I did a quick check on your code in
your second frame where the problem is occuring.

From my own html crafting experiences I usually get these display results from
missing end </table>, </tr>, </td> tags.  In your url, there is a missing </td>
and </tr>.  You might find this fixes it.  I'll check back.

Comment 2

[Martin Horwath]

Attachment: this testcase includes invalid html which is causing the problem.

Comment 3

[Keyser Sose]

See the problem on Windows 98 Mozilla Build #2000103104. Marking as new.

Comment 4

[Christine Hoffman]

From the testcase provided, 2 things are causing the problem. (1) The FONT tag 
contains a table (illegal), and (2) there is an unknown tag in the FONT tag. 

Comment 5

[Keyser Sose]

Marking INVALID due to bad HTML.

Comment 6

[Martin Horwath]

Keyser Sosez: Are you really sure, that this one should be marked as invalid ?
I think mozilla sould ignore invalid tags, and not render the table different.

Comment 7

[Stephan Niemz]

Attachment: same testcase without invalid HTML

Comment 8

[Stephan Niemz]

Reopening per above comment. Ksozez, please don't be so quick invalidating bugs.

I attached the same testcase again without the invalid HTML tag to show the
difference.  I agree that Mozilla should just ignore that tag.  NS 4.x does
this right, so adding 4xp (and testcase) keyword.

Comment 9

[Martin Horwath]

description for second testcase is not correct:
different rendering without <any unknown tag>

Comment 10

[bugzilla-invalid]

Adding self to cc:.



Bug is still INVALID if you ask me.

Comment 11

[Martin Horwath]

i think everyone knows that the html used in this examples is invalid. but this 
does not explain the reason why the table rendering is different and because of 
this, this bug should stay open until we know whats the reason for this 
behavior.

Comment 12

[Martin Horwath]

Over to parser to figure out what to do with this.

Comment 13

[Bernd]

WFM win98 CVs 2001-03-14

Comment 14

[Martin Horwath]

still the same problem on win98 buildid 2001031604 - this does not work for me.

Comment 15

[Frederic Crozat]

Still present on Linux buildid 2001031611

Comment 16

[karnaze (gone)]

The content model is wrong. Reassigning to harishd.

Comment 17

[Benjamin Mucci]

I don't know if it's a related bug but check that bug under MacOS:  Bug 83605

Here a HTML test doc
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=40741
Result under MacOS
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=40854

But under Win98 this page is perfect... Same prob under linux and MacOS!?

Comment 18

[harishd]

moving to m0.9.4.

Comment 19

[harishd]

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

Comment 20

[harishd]

Attachment: patch v1.1 [ when an end tag tries to find its target make sure that the tags in between do not gate ]

Comment 21

[vidur (gone)]

The early return in the first loop implies that we may not fall into the second
loop if there's a block container anywhere on the stack. This behavior is
different (though not necessarily incorrect) relative to the original code.
Harish is going to confirm that the new behavior is correct. Assuming he can,
sr=vidur.

One case that will behave different is <p>Some text <b>bold text</font>more
bold</b></p>. With the new code, the formatting should be the same, but the
content model might be different.

Comment 22

[Mats Palmgren (inactive)]

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

Comment 23

[Mats Palmgren (inactive)]

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

Comment 24

[harishd]

Attachment: patch v1.2 [ Treat userdefined tags as leaf ]

Comment 25

[vidur (gone)]

Harish's new patch attempts to deal with the problem that user-defined
(non-html) tags interfere with residual style activation. I believe his solution
to this is a bit too drastic.

I have a problem with the idea that user-defined tags will always be treated as
leaf elements. This is contrary to existing (and IE) behavior. It does fix the
problem that user-defined tags prevent residual style activation, but has the
potential to introduce new problems to existing content. A compromise may be to
have user-defined tags inherit their parent's behavior w.r.t. containership.

In the meantime, I'm comfortable with Harish checking in patch v1.1. The case
that I questioned in my previous comment is correctly dealt with because of
residual style activation.

Comment 26

[harishd]

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

Comment 27

[harishd]

Attachment: patch v1.3 [ Treat userdefined as inline element ]

Comment 28

[harishd]

Problem 1
---------
Misplaced /FONT was closing out TABLE. I've added logic such that if a residual
style tag ( inline element ) cannot contain a tag ( block element ) then it
cannot close it either. Which implies that the end tag is misplaced.

Problem 2
---------
Userdefined tag present between an inline element and a block element was
causing inline element to contain block element. The fix was to make userdefined
tag behave as an inline element.

Comment 29

[Heikki Toivonen (remove -bugzilla when emailing directly)]

r=heikki

Comment 30

[vidur (gone)]

sr=vidur. The latest patch makes user-defined tags act as inline elements in
terms of their containership. This is a reasonable compromise, though we may
still not be completely compatible with IE.

Comment 31

[tor]

a=tor on behalf of drivers.  In the future please use dependencies instead
of duplicates or mark the dup the other way around so that you're working
on a open bug.  Reopening for now so it shows up on appropriate queries.

Comment 32

[harishd]

FYI: To begin with I was working on this bug ( not bug 66772 ). Recently, bug
66772 got assigned to me and since it is WRMB I couldn't mark 66772 as a dup of
56245. That would make this a special case..though I totally understand your
concern. Also, I have commented on 66772 regarding this fix.

Comment 33

[harishd]

Added topembed keyword since this bug is a dup of bug 66772 ( WRMB ).

Comment 34

[Frederic Crozat]

Fixing url (page have moved..)

Comment 35

[Frederic Crozat]

Almost fixed (using Buildid 2001082221) but there is some artefact in second column 

Comment 36

[harishd]

Frederic: Could you be more specific on what exactly the problem is?

Comment 37

[harishd]

Attachment: Testcase [ Lays out differently compared to IE. Note: This is a different bug altogether ]

Comment 38

[Frederic Crozat]

Attachment: Correct layout (Netscape 4.78)

Comment 39

[Frederic Crozat]

Attachment: Broken layout (latest nightly build)

Comment 40

[harishd]

Frederic: I'm not sure if you're talking about the same thing ( i.e., space
between  "Programmes tele" and "titre" ) as my testcase ( id=46894 ). If it's
then we need to open up a new bug on it.

Comment 41

[Frederic Crozat]

I was talking about space between  "Programmes tele" and "titre"...
Are you sure it we should close this bug, since provided url still have exhibit
a cell location problem ?

Comment 42

[harishd]

The bug that we're seeing is entirely different from the original problem. We
therefore need to open up a new bug. I'll close this bug after I land the change
on the branch.

Comment 43

[harishd]

fixed on the trunk & branch. Marking FIXED.

Comment 44

[Moied]

verified fixed on branch build ID 20010926.

Comment 45

[Moied]

Marking bug as verified with build ID 20011116 on win2k