443616 - Table cells aligned incorrectly in xhtml but not in html

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Patrick C]

User-Agent:       Opera/9.51 (Windows NT 5.1; U; en)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9) Gecko/2008052906 Firefox/3.0

Correct rendering: http://www.yaroc.ch/ff3/test.html
  as png: http://www.yaroc.ch/ff3/correct_rendering.png
Incorrect rendering: http://www.yaroc.ch/ff3/test.xhtml
  as png: http://www.yaroc.ch/ff3/incorrect_rendering.png

apart from the ending xhtml everything is exactly the same

Reproducible: Always

Steps to Reproduce:
1.
2.
3.



have a look at for more direct consequences of this behaviour
http://www.pre.ethz.ch/facilities/

Comment 1

[Patrick C]

btw this only occurs with FF 3.0

Comment 2

[Ria Klaassen (not reading all bugmail)]

Regression range is
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1177105080&maxdate=1177110119
-> bug 84582.

Comment 3

[Patrick C]

Some more info:
  Setting the http header from
    "Content-Type: application/xhtml+xml; charset=utf-8"
  to
    "Content-Type: text/html; charset=utf-8"

solves the problems observed on http://www.pre.ethz.ch/

=> i.e. the http://www.pre.ethz.ch/facilities/  example can no longer be viewed

the example posted on http://www.yaroc.ch/ff3/ however still works

Note that the content type really should be "application/xhtml+xml" but FF3.0 somehow then produces the observed table cell alignment error.

Comment 4

[Patrick C]

No change yet with FF 3.0.1

Comment 5

[Ryan VanderMeulen [:RyanVM]]

What would make you think from watching this bug that anything would have changed between 3.0 and 3.0.1 to fix this bug?

Comment 6

[Patrick C]

(In reply to comment #5)
> What would make you think from watching this bug that anything would have
> changed between 3.0 and 3.0.1 to fix this bug?
> 

Nothing really. Sometimes I am a bit irrational - sorry.

Comment 7

[Ryan VanderMeulen [:RyanVM]]

That's OK. Feel free to verify that it's fixed once the bug is marked as such :-)

Comment 8

[Boris Zbarsky [:bzbarsky]]

This was fixed by the fix for bug 148810.  The reason this bug was happening is that the <script> forced the parser to wait for the external stylesheet at the point where the <script> appears in the DOM.  This led to an incremental layout while waiting, followed by an append of that last row.  You can get the same effect with no stylesheets involved by simply making the script body be "document.body.offsetWidth".

Now the key difference between the XTHML and HTML here is that the DOM is actually different: an HTML parser infers <tbody> after <table>, whereas the XHTML parser, of course, doesn't.  So in the XHTML case, we synthesize a row-group layout object to contain the rows.  But in the incremental append case, we were messing up and putting the new row after the rowgroup, not inside it, and rowspans don't cross rowgroup boundaries.  Bug 148810 fixed the append to put the row in the right rowgroup.

Patrick, you can test the fix out using a build from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ (make sure to use a separate profile while testing, so that it won't affect your existing profile).  The fix will appear in the major version after Firefox 3.5.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Pushed an automated regression test for this as http://hg.mozilla.org/mozilla-central/rev/10aa13d6d2aa

Comment 10

[Patrick C]

(In reply to comment #8)

> Patrick, you can test the fix out using a build from
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ (make 

Dear Boris,
Tested - it works :)
Looking forward for Firefox > 3.5
Thanks
Patrick