423823 - Overflowing tbody rows render background color for overflowing rows

Status: VERIFIED FIXED

(Core :: Layout: Tables, defect)

Description

[Plucera]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4

Se attached test-case. If the rows of the tbody overflows, background color renders outside its boundary.

Reproducible: Always

Steps to Reproduce:
1.Open test case
2.Set browser window to a size that makes the tbody rows overflow.

Actual Results:  
The background renders outside the tbody-box

Expected Results:  
No background renders outside

Comment 1

[Plucera]

Attachment: test case

Comment 2

[Plucera]

I may add that this is a FF3 bug only

Comment 3

[Michael Fayez]

This is a bug in Firefox 3 only not Firefox 2

Comment 4

[Michael Fayez]

Attachment: this file demonstrates the bug and also a bug of rules

Comment 5

[Matthew Knowlton]

I am also encountering this issue on a system. In my case we have a table that the height attribute has been set upon the tbody so that you can scroll through the tbody. I have different inline styles being applied to the tr tags. After the style for the set height is applied the background-colors that were on the rows before they disappeared into the overflow remain on the screen.

Comment 6

[Matthew Knowlton]

The second file already attached to this bug https://bugzilla.mozilla.org/attachment.cgi?id=311195
is a good represantation of how it is happening.

Comment 7

[Bernd]

Attachment: reduced testcase

Comment 8

[Bernd]

the key is the background-color on the row, if the background-color is set on the td everything is OK.

Comment 9

[Bernd]

hmm I did file this before in 2005 and it got revisited in 2006, taking the testcase there.

Comment 10

[Brian Polidoro]

Bug 317137 is about table columns.  This bug is about table rows.  Reopening.

Comment 11

[Brian Polidoro]

In bug Bug 438017 Ria found that this regressed from Bug 317375.

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Probably the best option is to treat rowgroups with overflow not 'visible' like rowgroups with 'opacity' --- start a new stacking context there.

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

That approach is simple enough.

Comment 18

[fantasai]

Comment on attachment 326572 [details] [diff] [review]
fix

I don't actually understand the data structures here well enough to know if IsScrolled()'s definition is right. Does this fix also work for -moz-hidden-unscrollable?

Please add reftests for '-moz-hidden-unscrollable' and 'scroll'

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 326572 [details] [diff] [review]
fix

IsScrolled would return false for -moz-hidden-unscrollable. I suppose we should handle that too.

Comment 20

[philippe (part-time)]

(In reply to comment #8)
> the key is the background-color on the row, if the background-color is set on
> the td everything is OK.
>
Bug 444000 has a test case where the background is assigned to the <td>. The key seems to specify explicitly:
table {border-collapse:collapse).

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix v2

Updated.

overflow:-moz-hidden-unscrollable actually doesn't work on table rowgroups at all; the layout is wrong. So I'm not testing that.

Comment 22

[fantasai]

Comment on attachment 328824 [details] [diff] [review]
fix v2

+ GetStyleDisplay()->mOverflowX == NS_STYLE_OVERFLOW_CLIP

I would have expected that to say mOverflowY, no? Does the patch work if it's just overflow-y: hidden;?

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

You can't have OVERFLOW_CLIP in only one direction.

Comment 24

[Lachezar Dobrev]

Attachment: Firefox 3 on Ubuntu 8.04 deterioration screenshot

I am attaching a screen-shot from Ubuntu with Mozilla Firefox 3.
The screen shot shows a severely deteriorated rendering of the attached test case.

Reproducing:
1. Open the 'This file demonstrates...' attachment.
2. Scroll the table body a few notches.
3. Refresh the page (not CTRL-F5, just F5).
4. Firefox has remembered the scroll position, and draws the table offset-ed.

Result: Firefox draws the table > body > tr background ignoring the clip area, starting at the 'correct' position, but misses the border.
The screen shot also demonstrates previously unstated 'funny behavior' with the table inner borders (see how they scroll inconsistently).

Testbed: Ubuntu 8.04 as of 14th of July 2008.

Our Intranet application is based on Firefox 2 and works great, seeing this deterioration with Firefox 3 has made us forbid company-wide migration due to the extensive use of scrollable tables throughout the application.

Comment 25

[fantasai]

roc, was that a "yes, that should be mOverflowY but it doesn't matter" or "no that actually should be mOverflowX"?

Lachezar, please don't report bugs by posting comments in existing ones. It's not helpful. We already know how to reproduce this one. If the bug you're seeing is not the one described here, file a new report.

Comment 26

[Robert O'Callahan (:roc) (email my personal email if necessary)]

That was a "it's fine for it to be mOverflowX".

Comment 27

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Sorry. Either both mOverflowX and mOverflowY are -moz-hidden-unscrollable or they both aren't, so it doesn't matter which one we test. Testing mOverflowY would be slightly more logical though so I'll change that.

Comment 28

[fantasai]

Comment on attachment 328824 [details] [diff] [review]
fix v2

r=fantasai with s/mOverflowX/mOverflowY/

Comment 30

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

Comment on attachment 328824 [details] [diff] [review]
fix v2

sr=dbaron

Comment 31

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Pushed 36c88ee6e809.

Comment 33

[Samuel Sidler (old account; do not CC)]

Let's get this in 1.9.0.x since it's a regression from Firefox 2.

roc: Can you request approval on a patch for 1.9.0.x?

Comment 34

[Samuel Sidler (old account; do not CC)]

Comment on attachment 328824 [details] [diff] [review]
fix v2

Approved for 1.9.0.2. Please land in CVS. a=ss

Comment 35

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Checked into 1.9.0.

Comment 37

[Al Billings [:abillings - ex-MoCo]]

Verified for 1.9.0.2 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.2) Gecko/2008090212 Firefox/3.0.2.

Comment 38

[Aakash Desai [:aakashd]]

verified FIXED on builds:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090721 Minefield/3.6a1pre ID:20090721044139

and

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1pre) Gecko/20090720 Shiretoko/3.5.1pre ID:20090720042942