Closed Bug 785684 Opened 7 years ago Closed 7 years ago

div content not clipped when display=table-cell


(Core :: Layout: Tables, defect, minor)

12 Branch
Not set





(Reporter: eugene, Assigned: mats)



(Keywords: regression, testcase)


(2 files, 1 obsolete file)

11.46 KB, application/octet-stream
780 bytes, text/html
Attached file HTML and screenshots
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20100101 Firefox/14.0.1
Build ID: 20120713134347

Steps to reproduce:

Create HTML that looks like
<style type="text/css">
.inner {
    overflow-x: hidden;
<div class="outer">
    <div class="inner">
       <input type=text value="Clipping issue with table-cell"/>

(see it live on )

Actual results:

content of inner div is not clipped as it ought to be

Expected results:

Firefox 11 clips it right
Component: Untriaged → Style System (CSS)
Product: Firefox → Core
Attached file html
Regression window(m-c)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120118 Firefox/12.0a1 ID:20120118122712
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120119 Firefox/12.0a1 ID:20120119023512

Regression window(m-i)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120118 Firefox/12.0a1 ID:20120118111412
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120118 Firefox/12.0a1 ID:20120118121914

Last good: 73eaf1199ff0
First bad: a915d5820eb8

Triggered by: a915d5820eb8	Mats Palmgren — Bug 524925 - Consolidate overflow clipping checks to nsFrame::ApplyOverflowClipping(); and fix some code style nits. part=5/6 r=roc
Blocks: 524925
Component: Style System (CSS) → Layout
Ever confirmed: true
Keywords: regression
Version: 14 Branch → 12 Branch
Thanks Alice.

Yes, I think this is an unintended change for overflow-x/y:hidden
on table/table-cell boxes (specifying both directions with
overflow:hidden still works and can be used instead).  Since we
have never supported scrolling a table-cell the old code did the
next best thing - clip in both directions.
Assignee: nobody → matspal
Keywords: testcase
OS: Windows XP → All
Hardware: x86 → All
What's odd is that specifying only overflow-y:hidden is ignored in old
versions, unlike overflow-x.  This asymmetry doesn't make sense to me.
It's been there since ApplyOverflowHiddenClipping first landed:
Severity: normal → minor
Component: Layout → Layout: Tables
Attached patch fix (obsolete) — Splinter Review
Attachment #655449 - Flags: review?(roc)
I think WebKit may treat overflow-y as the more important of the pair, and look only at it in some cases, since it's the more common direction of overflow, at least in Western text.

I tend to think the && behavior makes more sense than the || behavior -- it provides backwards compatibility with usage of 'overflow:hidden', but doesn't hide things that shouldn't be hidden.
Attachment #655449 - Flags: review?(roc) → review?(dbaron)
Yeah, now that I see that CSS3 actually allows hidden/visible:

Unlike what our style system says:

I'm also in favor of the new behavior, at least for hidden/visible.

I'll update the tests to match our current behavior.
Attachment #655449 - Attachment is obsolete: true
Attachment #655449 - Flags: review?(dbaron)
(In reply to Mats Palmgren [:mats] from comment #6)
> Yeah, now that I see that CSS3 actually allows hidden/visible:

That text was written by Bert without the agreement of the working group; I don't think the group ever intended it to allow that.

> Unlike what our style system says:
> cpp#4762

That code is correct, since hidden implies scrollability, and we really don't want to mix that with visible overflow.  (It's a lot of work, and I don't know of a good use case.)
Oh, OK.  I agree that combining scrollability with visible overflow
would be hard to implement (and weird to interact with), but I don't
see why we must support that as a result of supporting clipping in
one direction (which seems useful).

It seems easy to implement - make ApplyOverflowHiddenClipping
return the direction(s) to clip instead of bool, and in the places
we clip a rectangle based on the result just clip the rectangle in
the given direction(s) instead of both.  Is it more to it than that?

Anyway, since overflow-x:hidden implies a scoll box also when
overflow-y:visible then I'm neutral on the issue, and since you
prefer the new behavior I'll leave it as is.
Landed reftests that pass with the current rendering:
Closed: 7 years ago
Flags: in-testsuite+
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.