Closed Bug 423870 Opened 13 years ago Closed 12 years ago

[Fx2] Overflow hidden for block element in table cell causes element to be positioned incorrectly

Categories

(Core :: Layout: Tables, defect)

1.8 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: info, Unassigned)

References

Details

(Keywords: css2)

Attachments

(1 file, 3 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12

See submitted minimal test case. 

The div in the table cell is positioned incorrectly. The position varies depending on table height (eg. browser height).

- Removing the overflow value causes the div to position correctly
- Removing vertical-align: top for table cell removes the "jumpy" behaviour.


Reproducible: Always

Steps to Reproduce:
1. See test case
2. Resize browser window
Actual Results:  
The cell div is rendered incorrectly

Expected Results:  
The cell div is rendered below cell content
Attached file test case (obsolete) —
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → 1.8 Branch
Attached file Minimal Testcase (obsolete) —
The behaviour of this bug is very strange. I try to explain:

The bug happens in Fx2 and in Fx3, but in different ways. The problem is more evident if load the testcase in Fx2.

DIV (border red) should be into TD element, but it's not. It remains in the position it should be if table has a minimum height. If you change table height, it remains fixed in its wrong position. But! Note that if you increase table height so document vertical scrollbar appears, DIV is positioned correctly. 

On the contrary, in Fx3 vertical scrollbar has no effect, and if the DIV should be totally over TH element, DIV will be hidden instead!

Notice furthermore that document has no doctype. This bug do _not_ happens if there's a doctype (not html 3.2).

This bug happens only in this particular case. See testcase code for element structure and properties.
Attachment #310478 - Attachment is obsolete: true
Bug confirmed. Moved to Layout:Table. It needs to be reproduced also on Linux and Mac. Requesting blocking or wanted in 3.1
Status: UNCONFIRMED → NEW
Component: Layout → Layout: Tables
Ever confirmed: true
Flags: wanted1.9.1?
Flags: blocking1.9.1?
Keywords: css2, qawanted
QA Contact: layout → layout.tables
Whiteboard: [reproducible on Linux and Mac?]
Version: 1.8 Branch → Trunk
I can confirm the different behaviours in FF3 vs. FF2 but I still experience the issue with DOCTYPE given as XHTML-strict... 

Will add my test case again with doctypes and the same behaviour.
Attached file Bug with DOCTYPE xhtml-strict (obsolete) —
This happens only with Fx2. I think I'll create a new bug for Fx3, behaviours are different in too much cases.
Summary: overflow hidden for block element in table cell causes element to be positioned incorrectly → [Fx2] Overflow hidden for block element in table cell causes element to be positioned incorrectly
Version: Trunk → 1.8 Branch
Flags: wanted1.9.1?
Flags: wanted1.8.1.x?
Flags: blocking1.9.1?
Flags: blocking1.8.1.17?
Attached file Minimal Testcase #2
Ok, done. I also created a new minimal testcase for Fx2. I changed the doctype to html 4 because xhtml doesn't allow tbody in that position.

Notice that if you change the table height through javascript, the content is rendered well! You must change the height by hand to test the bug with different heights.
Attachment #327715 - Attachment is obsolete: true
Attachment #327753 - Attachment is obsolete: true
Unless this is a regression from a previous security fix (and it does not appear to be) then this kind of change is outside the scope of our security releases.
Flags: wanted1.8.1.x?
Flags: wanted1.8.1.x-
Flags: blocking1.8.1.17?
Flags: blocking1.8.1.17-
Regression caused by fixing Bug 300030, as reported by Martijn Wargers in Bug 443119 comment 3
Keywords: qawantedregression
Whiteboard: [reproducible on Linux and Mac?] → [regressed from bug 300030]
is this still broken? Its wfm, Or what should I do with the testcase?
I can confirm that the bug is fixed with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080916043910 Minefield/3.1b1pre

The bug is still valid for: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

I have no ability to test on 1.9.0.2
marking as wfm, as this is fixed on trunk, its not a security issue, neither a blocker that needs to be backported.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
If this is a Firefox 2 bug then it cannot be a regression from the reflow branch landing (bug 300030). It might still be a regression, but someone would have to identify a build that did in fact work.

But Bernd is probably right about it's chances of getting fixed in comment 12. If we can figure out what "fixed" it for 3.1pre we might be able to get that into 3.0.x but not likely 2.0
Keywords: regression
Whiteboard: [regressed from bug 300030]
You need to log in before you can comment on or make changes to this bug.