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

Status: RESOLVED WORKSFORME

(Core :: Layout: Tables, defect)

Description

[Plucera]

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

Comment 1

[Plucera]

Attachment: test case

Comment 2

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

Attachment: Minimal Testcase

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.

Comment 3

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

Bug confirmed. Moved to Layout:Table. It needs to be reproduced also on Linux and Mac. Requesting blocking or wanted in 3.1

Comment 4

[Plucera]

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.

Comment 5

[Plucera]

Attachment: Bug with DOCTYPE xhtml-strict

Comment 6

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

This happens only with Fx2. I think I'll create a new bug for Fx3, behaviours are different in too much cases.

Comment 7

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

Attachment: 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.

Comment 8

[Daniel Veditz [:dveditz]]

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.

Comment 9

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

Regression caused by fixing Bug 300030, as reported by Martijn Wargers in Bug 443119 comment 3

Comment 10

[Bernd]

is this still broken? Its wfm, Or what should I do with the testcase?

Comment 11

[Plucera]

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

Comment 12

[Bernd]

marking as wfm, as this is fixed on trunk, its not a security issue, neither a blocker that needs to be backported.

Comment 13

[Daniel Veditz [:dveditz]]

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