425498 - incorrect table rendering with rowspans and application/xhtml+xml pages that aren't cached

Status: RESOLVED WORKSFORME

(Core :: XML, defect)

Description

[Viktor Griph]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9pre) Gecko/2008032704 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9pre) Gecko/2008032704 Minefield/3.0pre

The rowspan of the table cells seems to be random when reloading a page with a targe table and the page isn't in cache. (Reloading the url gives different rendering results each time. (Some times it renders correctly.))

The expected rsult is achived when using http://ftek.chalmers.se/experimental/ff3bug.xhtml and reloading once, which only differs in that it is a non dynamic page, and thus can be cached. Shift-reload on the .xhtml page also triggers the rendering bug.

Reproducible: Sometimes

Steps to Reproduce:
1. Goto http://ftek.chalmers.se/experimental/ff3bug.php
2. reload the page a few times

Actual Results:  
The rendering of the multi row table cells are different between reloads.

Expected Results:  
The page should render as http://ftek.chalmers.se/experimental/ff3bug.xhtml (after one reload)

Comment 1

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008032801 Minefield/3.0pre

I see indeed differences after every reload.
Can you upload you testcase with the "add an attachment" link so it doesn't get lost?

Comment 2

[Viktor Griph]

Attachment: xhtml page showing the error when not cached

I attach the testcase. The php file is the same as the xhtml-file with a header() call to set the correct content type.

But I won't delete the pages linked in the original report. At least not until the bug is fixed.

Comment 3

[Alberto González Palomo]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1

I've found a similar problem, and have an additional test case.

The file I'll attach next is an XHTML file with a table that has two rows, and three cells. In the top row there are two cells, with the rightmost one having rowspan="2". In the bottom row there is only one cell.
It should display as two cells in the left column, and one cell in the right one, from top to bottom.

Starting from a certain amount of elements inside the tall cell, the rowspan seems to be ignored.
In the test case I've included an element counter. At 4733 elements it already fails, but removing one of the <div>s inside the "#container" element brings the count to 4564 and it works fine. The limit seems to be at 4577: one more element, and the problem appears.

I've tried different tree structures for the elements inside the #container, some flatter and other deeper, and that appears to be irrelevant.
When replacing the <span>s with text style tags like <i> and <b> the problem disappears, but with others like <strike> it's the same as with <span>.

The problem does not manifest itself if the exact same page is HTML instead of XHTML: after replacing the first two lines of the file (the XML declaration and the XHTML <html> tag) with <html>, and changing the file name extension from ".xhtml" to ".html", the table is rendered correctly. I've tried with up to 42082 elements, and no problem.

I suspect that bug #289028 could be related: in the original page where I had this problem, the second row was not rendered immediately. It looks like the table was first made without the last row, the rowspan ignored as it went below the table bottom, and then the last row added.

Also bug #382002 seems similar in that it shows problems with the rowspans, although they are different. It has a nice test case.

Comment 4

[Alberto González Palomo]

Attachment: File showing the wrong table rendering, XHTML.

There are 4733 elements in the container div inside the rowspan="2" cell.
Make this file HTML, or bring the element count down to 4577, and the rendering becomes correct in my machine.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1

Comment 5

[Ria Klaassen (not reading all bugmail)]

Regression range for the testcase in comment 2 is:
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1170186720&maxdate=1170192839
which points to Bug 18333.

Comment 6

[Ria Klaassen (not reading all bugmail)]

The case of comment 4 regressed from the same bug (Bug 18333).

Comment 7

[Henri Sivonen (:hsivonen)]

Similar to bug 344281?

Comment 8

[Curtis Bright]

Attachment: XHTML Long Rowspan Test

I ran into this problem too.  This is a simplified test page with 10000 rows.  Every number should be in the same column, but for me only 2885 are, with less when I quickly refresh the page.

Comment 9

[Jan Holthusen]

Attachment: Another test case

I ran into the same problem and can confirm this bug with Firefox 3.5rc1. I really hoped this would be fixed in 3.5 but since serving as HTML works fine, we probably have to live with it for another release.

Comment 10

[Marc Dionne]

I'm seeing (and many others are as well) what I think is the same bug with pages generated by gitweb's blame feature, with the 3.5 release on both Linux and Windows.  The mangled display seems to some from rowspan attributes that end up effecting spanning a different number of lines at every reload.

This is very repeatable - it shows up with pretty much every page generated by the gitweb blame feature and served as xml.

For instance the following page:
http://git.openafs.org/?p=openafs.git;a=blame;f=.gitignore;hb=master

will usually display incorrectly, and slightly differently every time it is reloaded.

Comment 11

[Cosmin Muntean [:cmuntean], Ecosystem QA]

Firefox: 47.0, Build ID  20160604131506
User Agent  Mozilla/5.0 (Windows NT 5.1; rv:47.0) Gecko/20100101 Firefox/47.0

I have tested this issue on the latest Firefox (47.0) release and latest Nightly (50.0a1- Build ID: 20160627030215) build, but I could not reproduce it. For testing this I have used all the provided test cases, but after every reload the pages are correctly rendering.

Is this still reproducible on your end? If yes, can you please retest this using latest Firefox release and latest Nightly build (https://nightly.mozilla.org/) and report back the results ? When doing this, please use a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause (https://goo.gl/PNe90E).

Comment 12

[Curtis Bright]

(In reply to Cosmin Muntean [:CosminMCG] (PTO until 07/22/2016) from comment #11)
> Is this still reproducible on your end?

No, this is no longer reproducible for me.  Some quick testing suggests it was fixed in Firefox 9.0.

Comment 13

[Cosmin Muntean [:cmuntean], Ecosystem QA]

Curtis, thanks for retesting this bug. 
Based on comment 12 I will mark this issue as Resolved - WFM.