Closed Bug 423823 Opened 17 years ago Closed 16 years ago

Overflowing tbody rows render background color for overflowing rows

Categories

(Core :: Layout: Tables, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: info, Assigned: roc)

References

Details

(4 keywords)

Attachments

(5 files, 1 obsolete file)

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
Attached file test case
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
This is a bug in Firefox 3 only not Firefox 2
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.
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.
Attached file reduced testcase
the key is the background-color on the row, if the background-color is set on the td everything is OK.
hmm I did file this before in 2005 and it got revisited in 2006, taking the testcase there.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → UNCONFIRMED
Keywords: regression, testcase
Resolution: DUPLICATE → ---
Bug 317137 is about table columns. This bug is about table rows. Reopening.
Status: UNCONFIRMED → NEW
Ever confirmed: true
In bug Bug 438017 Ria found that this regressed from Bug 317375.
Depends on: 317375
Flags: wanted1.9.0.x?
Flags: blocking1.9.1?
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.
Attached patch fix (obsolete) — Splinter Review
That approach is simple enough.
Assignee: nobody → roc
Status: NEW → ASSIGNED
Attachment #326572 - Flags: superreview?(dbaron)
Attachment #326572 - Flags: review?(dbaron)
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)
(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).
Attached patch fix v2Splinter Review
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 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.
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.
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 on attachment 328824 [details] [diff] [review] fix v2 r=fantasai with s/mOverflowX/mOverflowY/
Attachment #328824 - Flags: review?(fantasai.bugs) → review+
Comment on attachment 328824 [details] [diff] [review] fix v2 sr=dbaron
Attachment #328824 - Flags: superreview?(dbaron) → superreview+
Pushed 36c88ee6e809.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago16 years ago
Resolution: --- → FIXED
Flags: in-testsuite+
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+
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
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.
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
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: