Plucera Reporter
	Description • 17 years ago

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

	Plucera Reporter
	Comment 2 • 17 years ago

I may add that this is a FF3 bug only

	Michael Fayez
	Comment 3 • 17 years ago

This is a bug in Firefox 3 only not Firefox 2

	Matthew Knowlton
	Comment 5 • 16 years ago

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.

	Matthew Knowlton
	Comment 6 • 16 years ago

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.

	Bernd
	Comment 8 • 16 years ago

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

	Bernd
	Comment 9 • 16 years ago

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

	Brian Polidoro
	Comment 10 • 16 years ago

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

	Brian Polidoro
	Comment 11 • 16 years ago

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

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 16 • 16 years ago

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

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 17 • 16 years ago

That approach is simple enough.

	fantasai
	Comment 18 • 16 years ago

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'

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 19 • 16 years ago

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

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

	philippe (part-time)
	Comment 20 • 16 years ago

(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).

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 21 • 16 years ago

Updated.

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

	fantasai
	Comment 22 • 16 years ago

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;?

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 23 • 16 years ago

You can't have OVERFLOW_CLIP in only one direction.

	Lachezar Dobrev
	Comment 24 • 16 years ago

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.

	fantasai
	Comment 25 • 16 years ago

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.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 26 • 16 years ago

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

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 27 • 16 years ago

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.

	fantasai
	Comment 28 • 16 years ago

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

r=fantasai with s/mOverflowX/mOverflowY/

	David Baron :dbaron:
	Comment 30 • 16 years ago

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

sr=dbaron

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 31 • 16 years ago

Pushed 36c88ee6e809.

	Samuel Sidler (old account; do not CC)
	Comment 33 • 16 years ago

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?

	Samuel Sidler (old account; do not CC)
	Comment 34 • 16 years ago

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

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

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 35 • 16 years ago

Checked into 1.9.0.

	Al Billings [:abillings - ex-MoCo]
	Comment 37 • 16 years ago

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.

	Aakash Desai [:aakashd]
	Comment 38 • 15 years ago

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