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/
btw this only occurs with FF 3.0
Regression range is http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1177105080&maxdate=1177110119 -> bug 84582.
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.
No change yet with FF 3.0.1
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?
(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.
That's OK. Feel free to verify that it's fixed once the bug is marked as such :-)
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.
Pushed an automated regression test for this as http://hg.mozilla.org/mozilla-central/rev/10aa13d6d2aa
(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