Overflowing tbody rows render background color for overflowing rows

VERIFIED FIXED

Status

()

Core
Layout: Tables
VERIFIED FIXED
10 years ago
8 years ago

People

(Reporter: Plucera, Assigned: roc)

Tracking

(4 keywords)

Trunk
x86
Windows XP
regression, testcase, verified1.9.0.2, verified1.9.1
Points:
---
Bug Flags:
blocking1.9.1 +
wanted1.9.0.x +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments, 1 obsolete attachment)

(Reporter)

Description

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

Comment 1

10 years ago
Created attachment 310440 [details]
test case
(Reporter)

Comment 2

10 years ago
I may add that this is a FF3 bug only
Component: General → Layout: Tables
Product: Firefox → Core
QA Contact: general → layout.tables
Version: unspecified → Trunk

Comment 3

10 years ago
This is a bug in Firefox 3 only not Firefox 2

Comment 4

10 years ago
Created attachment 311195 [details]
this file demonstrates the bug and also a bug of rules

Comment 5

9 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.

Comment 6

9 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.

Comment 7

9 years ago
Created attachment 322419 [details]
reduced testcase

Comment 8

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

Comment 9

9 years ago
hmm I did file this before in 2005 and it got revisited in 2006, taking the testcase there.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 317137

Updated

9 years ago
Status: RESOLVED → UNCONFIRMED
Keywords: regression, testcase
Resolution: DUPLICATE → ---

Comment 10

9 years ago
Bug 317137 is about table columns.  This bug is about table rows.  Reopening.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 11

9 years ago
In bug Bug 438017 Ria found that this regressed from Bug 317375.
Depends on: 317375

Updated

9 years ago
Duplicate of this bug: 438017

Updated

9 years ago
Duplicate of this bug: 439444

Updated

9 years ago
Duplicate of this bug: 438827

Updated

9 years ago
Duplicate of this bug: 439653

Updated

9 years ago
Flags: wanted1.9.0.x?
Flags: blocking1.9.1?

Updated

9 years ago
Blocks: 317375
No longer depends on: 317375
Probably the best option is to treat rowgroups with overflow not 'visible' like rowgroups with 'opacity' --- start a new stacking context there.
Created attachment 326572 [details] [diff] [review]
fix

That approach is simple enough.
Assignee: nobody → roc
Status: NEW → ASSIGNED
Attachment #326572 - Flags: superreview?(dbaron)
Attachment #326572 - Flags: review?(dbaron)
Attachment #326572 - Flags: review?(fantasai.bugs)

Comment 18

9 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'
Comment on attachment 326572 [details] [diff] [review]
fix

IsScrolled would return false for -moz-hidden-unscrollable. I suppose we should handle that too.
Attachment #326572 - Attachment is obsolete: true
Attachment #326572 - Flags: superreview?(dbaron)
Attachment #326572 - Flags: review?(fantasai.bugs)
Attachment #326572 - Flags: review?(dbaron)
Blocks: 424585
No longer blocks: 424585
(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).

Created attachment 328824 [details] [diff] [review]
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.
Attachment #328824 - Flags: superreview?(dbaron)
Attachment #328824 - Flags: review?
Attachment #328824 - Flags: review? → review?(fantasai.bugs)

Comment 22

9 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;?
You can't have OVERFLOW_CLIP in only one direction.

Comment 24

9 years ago
Created attachment 329428 [details]
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

9 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.
That was a "it's fine for it to be mOverflowX".
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

9 years ago
Comment on attachment 328824 [details] [diff] [review]
fix v2

r=fantasai with s/mOverflowX/mOverflowY/
Attachment #328824 - Flags: review?(fantasai.bugs) → review+

Updated

9 years ago
Duplicate of this bug: 449598
Comment on attachment 328824 [details] [diff] [review]
fix v2

sr=dbaron
Attachment #328824 - Flags: superreview?(dbaron) → superreview+
Pushed 36c88ee6e809.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → FIXED
Flags: in-testsuite+

Updated

9 years ago
Duplicate of this bug: 444000
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?
Flags: wanted1.9.0.x? → wanted1.9.0.x+
Attachment #328824 - Flags: approval1.9.0.2?
Comment on attachment 328824 [details] [diff] [review]
fix v2

Approved for 1.9.0.2. Please land in CVS. a=ss
Attachment #328824 - Flags: approval1.9.0.2? → approval1.9.0.2+
Checked into 1.9.0.
Flags: blocking1.9.1? → blocking1.9.1+
Keywords: fixed1.9.0.2

Updated

9 years ago
Duplicate of this bug: 452473
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.
Keywords: fixed1.9.0.2 → verified1.9.0.2
Keywords: fixed1.9.1
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
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
You need to log in before you can comment on or make changes to this bug.