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

NEW
Unassigned

Status

()

Core
Layout: Tables
--
major
10 years ago
5 years ago

People

(Reporter: Todd Randa, Unassigned)

Tracking

({regression, testcase})

Trunk
regression, testcase
Points:
---
Bug Flags:
wanted1.9.1 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(5 attachments, 4 obsolete attachments)

(Reporter)

Description

10 years ago
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.
(Reporter)

Comment 1

10 years ago
OS = XP
(Reporter)

Comment 2

10 years ago
Not sure how to attach sample files???
(Reporter)

Comment 3

10 years ago
Created attachment 336678 [details]
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.
Component: General → Layout: Tables
Product: Firefox → Core
QA Contact: general → layout.tables
Version: unspecified → 1.9.0 Branch
(Reporter)

Comment 4

10 years ago
Is anyone going to work this defect?
(Reporter)

Updated

10 years ago
Severity: normal → major
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.
(Reporter)

Comment 6

10 years ago
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.
(Reporter)

Comment 7

10 years ago
Created attachment 337761 [details]
Screen print presenting the problem

See bug comments for information regarding this attachment.
(Reporter)

Comment 8

10 years ago
Created attachment 337763 [details]
screenshot: FF3 behavior [BUGGY]

See bug comments for information regarding this attachment.
(Reporter)

Comment 9

10 years ago
Created attachment 337764 [details]
See bug comments for information regarding this attachment.

See bug comments for information regarding this attachment.
(Reporter)

Comment 10

10 years ago
Created attachment 337765 [details]
screenshot: IE / FF2 behavior

See bug comments for information regarding this attachment.
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])
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.)
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.
(Reporter)

Comment 14

10 years ago
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.
(Reporter)

Comment 15

10 years ago
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?
(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.
(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.
(Reporter)

Comment 18

10 years ago
Created attachment 337771 [details]
other files linked to the html file

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

Comment 19

10 years ago
I've sent the other files. I hope this helps..
(Reporter)

Comment 20

10 years ago
Have you re-created the problem?
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted, regression, testcase
OS: Windows XP → All
Hardware: PC → All
Version: 1.9.0 Branch → Trunk
(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.
Keywords: regressionwindow-wanted
Attachment #336678 - Attachment description: html page for recreating the problem → html page for recreating the problem (only works if you download "other files")
Attachment #336678 - Attachment description: html page for recreating the problem (only works if you download "other files") → html page for recreating the problem (only works if you download with "other files" zip bundle)
Attachment #337763 - Attachment description: See bug comments for information regarding this attachment. → screenshot: FF3 behavior
Attachment #337765 - Attachment description: See bug comments for information regarding this attachment. → screenshot: IE / FF2 behavior
Attachment #337764 - Attachment is obsolete: true
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.)
Attachment #337761 - Attachment is obsolete: true
Attachment #337763 - Attachment description: screenshot: FF3 behavior → screenshot: FF3 behavior [BUGGY]
(Reporter)

Comment 24

10 years ago
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.
(Reporter)

Comment 25

10 years ago
Created attachment 338018 [details]
testcase 2

Single file test case.
(Reporter)

Comment 26

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

no longer needed. I put together a single file test case.
Attachment #337771 - Attachment is obsolete: true
(Reporter)

Updated

10 years ago
Attachment #336678 - Attachment is obsolete: true
(Reporter)

Comment 27

10 years ago
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.
Attachment #338018 - Attachment description: Single file test case. → testcase 2
Created attachment 338040 [details]
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
Created attachment 338043 [details]
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.
(Reporter)

Comment 30

10 years ago
Not sure what all this means.. Does anyone know how I can get this to work? I would really appreciate any suggestions..
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?
Blocks: 406568
Keywords: regressionwindow-wanted

Comment 32

10 years ago
@  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>.
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?
Blocks: 375304
No longer blocks: 406568
Flags: blocking1.9.1?
Flags: blocking1.9.1? → wanted1.9.1+

Comment 34

9 years ago
(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.
Based on Comment 34 - removing the qawanted keyword.
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.