Closed Bug 221154 Opened 23 years ago Closed 2 years ago

table cells do not support 'overflow' correctly

Categories

(Core :: Layout: Tables, defect)

defect

Tracking

()

RESOLVED FIXED
124 Branch
Webcompat Priority P3
Tracking Status
firefox124 --- fixed

People

(Reporter: dbaron, Assigned: emilio)

References

(Blocks 2 open bugs, Regressed 1 open bug)

Details

(Keywords: css2, testcase)

Attachments

(3 files, 3 external files)

Table cells do not support 'overflow' correctly. They don't support 'auto' and 'scroll' at all, and their support for 'hidden' is incorrect (thanks to the hack that fixet bug 221140).
Keywords: testcase
Isn't this just bug 39683, since in CSS21 'height' and 'width' on a 'table-cell' are actually 'min-width' and 'min-height': <http://www.w3.org/TR/CSS21/tables.html#height-layout>: > In CSS 2.1, the height of a cell box is the maximum of the table cell's > 'height' property and the minimum height required by the content (MIN). A > value of 'auto' for 'height' implies a that the value MIN will be used for > layout. CSS 2.1 does not define what percentage values of 'height' refer to > when specified for table cells. <http://www.w3.org/TR/CSS21/tables.html#auto-table-layout>
Anne, no this bug is about a design flaw in table cell frame construction where it does not wrap the frame in to a scollable frame like the row group frame does (http://lxr.mozilla.org/seamonkey/source/layout/html/style/src/nsCSSFrameConstructor.cpp#2601)
I'm pretty sure this is related, so I didn't want to open another bug. I've attached another testcase file named testcase2.html which is a barely edited file of where I encountered the issue. Note that the pre element does not fully display all of its contents, it seems to end after line 2523 of the testcase2.html file, and is followed by a significant amount of blank space before the end of the document is reached. The pre element is styled by overflow: scroll associated by the class="log". This element is in a td element which is why I think it is related to this bug.
Assignee: layout.tables → nobody
QA Contact: madhur → layout.tables
Okay, this really is a non sense. This bug exists since 2003. How many releases did we have since then? How am I supposed to do vertical layout? Assigned to nobody? Great care Mozilla, it works perfectly with WebKit. Hope there will be Chrome Frame for Firefox soon, and popular.
Attached file another test case —
(In reply to Dusan Maliarik from comment #7) > Okay, this really is a non sense. This bug exists since 2003. I just filed what turned out to be a duplicate so I'd second Dusan's sentiment (another 7 years later). All other browsers (IE9+) handle this consistently.
No longer blocks: 1445634
Assignee: nobody → mats
Webcompat Priority: --- → ?

We do not have any live site examples. The only issue we had has been fixed by the website itself.

Webcompat Priority: ? → P3

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: MatsPalmgren_bugz → nobody
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 7 duplicates and 10 votes.
:dholbert, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dholbert)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(dholbert)
Duplicate of this bug: 1869021
Flags: needinfo?(emilio)
Duplicate of this bug: 1488810
Assignee: nobody → emilio
Attachment #9371652 - Attachment description: WIP: Bug 221154 - Make overflow work on table cells. → Bug 221154 - Make overflow work on table cells. r=TYLin,dholbert
Status: NEW → ASSIGNED
Flags: needinfo?(emilio)

This doesn't change behavior but it's a prerequisite to supporting a
scrollframe properly (since we want the padding inside the scrolled
area).

This follows a bit what nsFieldSetFrame does.

Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/274f73457318 Make ::-moz-table-content inherit padding from the table cell. r=dholbert https://hg.mozilla.org/integration/autoland/rev/166b593890ef Make overflow work on table cells. r=dholbert
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/44096 for changes under testing/web-platform/tests
Upstream PR was closed without merging
No longer blocks: 1488810
Attachment #9373219 - Attachment description: Bug 221154 - Make ::-moz-table-content inherit padding from the table cell. r=dholbert,TYLin → Bug 221154 - Make ::-moz-table-content inherit padding from the table cell. r=dholbert
Attachment #9371652 - Attachment description: Bug 221154 - Make overflow work on table cells. r=TYLin,dholbert → Bug 221154 - Make overflow work on table cells. r=dholbert

The padding changes causes some sizes in the child to not exactly be
nscoord_MAX when overflowing, but a slightly smaller value, not hitting
the width == nscoord_MAX || height == nscoord_MAX condition in
FinishStoreOverflow().

The other one is similar, where an nscoord_MAX value gets to bidi
reordering, where it didn't before. It doesn't seem problematic /
anything that wouldn't otherwise happen with a regular block with
padding.

Depends on D197978

Flags: needinfo?(emilio)
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/e194aafccb17 Make ::-moz-table-content inherit padding from the table cell. r=dholbert https://hg.mozilla.org/integration/autoland/rev/271097ebb915 Make overflow work on table cells. r=dholbert https://hg.mozilla.org/integration/autoland/rev/2211ddf306e0 Tweak a few crashtest assertion counts. r=dholbert
Upstream PR merged by moz-wptsync-bot
Regressions: 1876354
Regressions: 1877719
Regressed by: 1877591
No longer regressed by: 1877591
Regressions: 1877591
Regressions: 1880550
Regressions: 1883872
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: