453486 - HTML Table not rendering properly after firefox update to 3.0.1. Row not displaying at the top of the table.

Status: RESOLVED INCOMPLETE

(Core :: Layout: Tables, defect)

Description

[Todd Randa]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Firefox/3.0.1

I have a fairly sophisticated html page rendered using custom tags within a jsp. The page also has quite a bit of JavaScript and css. The display tag on the page is not rendering correctly anymore after the latest firefox update to 3.0.1. The display tag resides in a div container tag. It appears that the height of the table is being styled to the height of the div. The problem is the rows seem to be valign-ing middle instead of top. If there is one row, the row is displayed vertically in the middle of the table. If there are several rows, but not enough to fill the height, each row is stretched so that all rows (or one) take up the full height of the table. I've used an html beautifier to see if my html is syntactically incorrect, but found nothing. I'm really stuck here. I'm ready to roll this product out to production and do not want to restrict the user to only using IE.. Please help.

Reproducible: Sometimes

Steps to Reproduce:
1.Sometimes it renders correctly the first time displayed, and then if refreshed, it will render incorrectly.
2.
3.
Actual Results:  
View the HTML page and if the first rendering does not recreate the problem, then click the browser refresh button.

Expected Results:  
The table row will valign middle instead of at the top.

The table row should have valign-ed top.

Comment 1

[Todd Randa]

OS = XP

Comment 2

[Todd Randa]

Not sure how to attach sample files???

Comment 3

[Todd Randa]

Attachment: html page for recreating the problem (only works if you download with "other files" zip bundle)

This attachment is an html page that demonstrates the problem.

Comment 4

[Todd Randa]

Is anyone going to work this defect?

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Could you give steps to reproduce, expected results, and actual results that don't use words like "correctly"?  In other words, tell somebody how to tell if they're seeing the problem.

Comment 6

[Todd Randa]

Thanks for the response. Sorry for using the word correctly. I am aware that IE may be displaying it the way I would like because it it's not a W3C complaint browser. What gives me suspicion that it should render the same way in FF is it used to render the same way in FF until an update to the latest version of FF. 

One thing to note: You should be able to recreate the problem by opening up the HTML page that I attached to this defect. I tried the link to the attachment in this defect and noticed that when it displayed it didn't present the problem, but when I open the actual file that I attached residing on my laptop it re-created the problem. Let me know if I can email you the file as an attachment if you cannot recreate the problem with this page. Note, my pc is heavily protected with firewall and virus protection etc. 

I've also attached several image files in an effort to clearly define the problem. The file names and what the image displays is as follows:

FF-1.jpg Shows a screen print of a list page in the application where the list contains multiple rows.
FF-2.jpg Shows a screen print of a single row in the same list.
IE-1.jpg Shows the same page displayed in FF-1.jpg but rendered in current version of the IE browser.
IE-2.jpg Shows the same page displayed in FF-2.jpg but rendered in the current version of the IE browser.

Comment 7

[Todd Randa]

Attachment: Screen print presenting the problem

See bug comments for information regarding this attachment.

Comment 8

[Todd Randa]

Attachment: screenshot: FF3 behavior [BUGGY]

See bug comments for information regarding this attachment.

Comment 9

[Todd Randa]

Attachment: See bug comments for information regarding this attachment.

See bug comments for information regarding this attachment.

Comment 10

[Todd Randa]

Attachment: screenshot: IE / FF2 behavior

See bug comments for information regarding this attachment.

Comment 11

[Daniel Holbert [:dholbert]]

Your screenshots seem to be using a web page that's quite unlike the testcase you've attached here.

Can you provide screenshots showing the expected vs buggy rendering of your attached testcase? (attachment 336678 [details])

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm asking you to say how somebody looking at your testcase can tell whether it is being displayed correctly or incorrectly, rather than simply saying it's incorrect.

For example:  

Steps to reproduce:  load attachment 336678 [details]
Expected results: the words "Export options" appear in the lower *right*
Actual results: the words "Export options" appear in the lower *left*

(Note that I'm making those up.)

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It looks like the file you attached has links to lots of other files that you didn't attach.  Since we don't have them, there's no way we can see the bug.

Comment 14

[Todd Randa]

Ok.. sorry..

Steps to reproduce. Download HTML file to your local pc environment. (For some
reason just clicking on the link doesn't present the problem. I'm hoping that
uploading the file doesn't change anything which is causing it to display
correctly).
Expected results. Single row will display valign top in the table.
Actual results. Single row is displaying valign middle even if I add an
attribute to the td tag to valign top.

Comment 15

[Todd Randa]

All of the links are dynamic and are rendered through the application. There should be no need to have all of the pages since I'm not having problems with the links, I'm having problems with the table on the page displaying the rows at the top of the table instead of the middle. Have you read the information I sent?

Comment 16

[Daniel Holbert [:dholbert]]

(In reply to comment #15)
> All of the links are dynamic and are rendered through the application.

Um.. How about these, for example:
<link rel="STYLESHEET" href="displayTagRenderingDefect_files/ptaxStyles.css">

<script type="text/javascript" src="displayTagRenderingDefect_files/dwrUtil.js">

Those are references to local files, which don't get uploaded with your HTML document, and which we don't have available to us.

> Have you read the information I
> sent?

Yes. Have you tried your steps-to-reproduce from comment 14?  I just did, and it looks the exact same as when I view it on the bug, for the reasons stated above and in comment 13.

Comment 17

[Daniel Holbert [:dholbert]]

(In reply to comment #16)
> (In reply to comment #15)
> > All of the links are dynamic and are rendered through the application.
> 
> Um.. How about these, for example:

Oh, sorry -- I misunderstood your comment.  I thought you were suggesting they were bundled with the HTML somehow.

Still, though -- if you can't reproduce the bug when you view the attached file (per comment 14), we can't either. :)  As I said, it looks the exact same when I download it as when I view it as an attachment here.

Comment 18

[Todd Randa]

Attachment: other files linked to the html file

Here are all of the files that are referenced in the html page. .js, .css etc.

Comment 19

[Todd Randa]

I've sent the other files. I hope this helps..

Comment 20

[Todd Randa]

Have you re-created the problem?

Comment 21

[Daniel Holbert [:dholbert]]

Yes -- I posted your testcase (with the name / address / acct # changed) and files at
   http://people.mozilla.org/~dholbert/tests/453486/test.html
which is now set as the URL of this bug.

I can confirm this behavior:
  Firefox 2.0.0.16: the row with "Doe, John" is at the top of the table
  Firefox 3.0.1: the row with "Doe, John" is vertically centered (halfway down the page)

However, with such a large testcase that uses so many external resources, it's hard to tell exactly what's going on and what correct behavior *should* be.  If either the reporter or a QA person could minimize the testcase to determine the cause of the difference between FF2 and FF3, that'd be much appreciated.

FWIW, I tried viewing the URL in Opera and WebKit, and they both shrink the table to a height of 1 row.  So, we can't really compare against their behavior.

Comment 22

[Daniel Holbert [:dholbert]]

(In reply to comment #21)
> If
> either the reporter or a QA person could minimize the testcase to determine the
> cause of the difference between FF2 and FF3, that'd be much appreciated.

Also, a regression-range would be awesome.

Comment 23

[Daniel Holbert [:dholbert]]

Comment on attachment 337761 [details]
Screen print presenting the problem

Obsoleting two screenshots to clean things up a bit. (I've left the other two screenshots, which show a one-entry table, as is present in the testcase & URL.  I renamed them to make their contents more clear.)

Comment 24

[Todd Randa]

I have minimized the test case by trimming the html page down to just the table and there are no longer any external resources. All style is contained in the HTML page a style container tag. I will upload the file. Name : SingleFileTestCase.htm.

Comment 25

[Todd Randa]

Attachment: testcase 2

Single file test case.

Comment 26

[Todd Randa]

Comment on attachment 337771 [details]
other files linked to the html file

no longer needed. I put together a single file test case.

Comment 27

[Todd Randa]

Comment on attachment 336678 [details]
html page for recreating the problem (only works if you download with "other files" zip bundle)

no longer needed. Single file test case is attached.

Comment 28

[Daniel Holbert [:dholbert]]

Attachment: testcase 2+borders

Here's that exact same single-file testcase, with an orange border added to the "staticTable" table and a green-dashed border added to its cells.

This highlights the differences between IE, FF2, and FF3 on this testcase.
 IE8: short table, short td
 FF2: tall table, short td
 FF3: tall table, tall td

Comment 29

[Daniel Holbert [:dholbert]]

Attachment: testcase 2+borders+no child selector

This testcase just changes the child selector into a descendant selector:
-table.staticTable>tbody        {  /* child selector syntax which IE6 and older do not support*/
+table.staticTable tbody        {  /* child selector syntax which IE6 and older do not support*/

This change makes IE8 change its behavior to match FF3.  This suggests that IE is mis-handling the child selector syntax. (because there *shouldn't* be any difference between child selector and descendant selector in this case)

(Note that FF2 still doesn't match -- it looks like the "overflow: auto" and "overflow-x: hidden" declarations both make the cell shrink in FF2, probably due a bug there.)

So AFAICT, this isn't a bug in Firefox 3.

Comment 30

[Todd Randa]

Not sure what all this means.. Does anyone know how I can get this to work? I would really appreciate any suggestions..

Comment 31

[Ria Klaassen (not reading all bugmail)]

Row too low,
works: 2007120419
fails: 2007120419
Regression window: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2007-12-04+18%3A00&maxdate=2007-12-04+20%3A00
Caused by Bug 406568 or Bug 375304? Maybe someone should try to back out one of them?

Comment 32

[philippe (part-time)]

@  Daniel (comment 28 and 29)
 
1. IE 8b is in *quirks* mode and thus behaves like IE 6 (lack of DocType). IE 6 never had support for the '>' selector. Try adding a doctype and see shat IE 8 does in both cases.

2. Opera and WEbKit have, afaik, no support for the 'height' property on <tbody> - height is auto. the row is as tall as its content

As I see it, Gecko 1.9 is correct on those testcases, the row is as tall as the set height of <tbody>.

Comment 33

[Boris Zbarsky [:bzbarsky]]

Actually, almost certainly a "regression" from bug 375304.

Should we be special-casing table bodies here somehow so they'll continue to really stretch out as they used to?

Comment 34

[Tim Riley [:timr]]

(In reply to comment #22)
> 
> Also, a regression-range would be awesome.

Regression range identified by Ria in Comment #31.  Removed qawanted keyword.  Let us know if there is any additional help wanted.

Comment 35

[Simona Badau, Desktop QA]

Based on Comment 34 - removing the qawanted keyword.

Comment 36

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 37

[Daniel Holbert [:dholbert]]

Closing as "incomplete" -- while a behavior-change was identified here (between Firefox 2 and 3), we never arrived at a definitive assessment that the new behavior was wrong.

Our behavior still seems to match the Firefox 3 behavior (tall table, tall td, centered text), and Chromium happens to have the same behavior, so that's two votes in favor for our current behavior making some sense, and it presents potential webcompat risk if we were to hypothetically change. Hence, not likely to take action here, based on the info that we've got at this point.

Comment 38

[Daniel Holbert [:dholbert]]

(er, correcting resolution to the one I meant to use)

I spun off bug 1833444, and filed some bugs in other browsers [linked there], for something that I noticed about the bordercolor attribute when comparing renderings of the testcases here.