Closed Bug 785684 Opened 7 years ago Closed 7 years ago

div content not clipped when display=table-cell

Categories

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

12 Branch
defect
Not set
minor

Tracking

()

RESOLVED WONTFIX

People

(Reporter: eugene, Assigned: mats)

References

Details

(Keywords: regression, testcase)

Attachments

(2 files, 1 obsolete file)

11.46 KB, application/octet-stream
Details
780 bytes, text/html
Details
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
<code>
<style type="text/css">
.inner {
    display:table-cell;
    max-width:150px;
    overflow-x: hidden;
}
</style>
<div class="outer">
    <div class="inner">
       <input type=text value="Clipping issue with table-cell"/>
    </div>
</div>    

(see it live on http://jsfiddle.net/MT6Xq/ )


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)
Good:
http://hg.mozilla.org/mozilla-central/rev/58e933465c36
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120118 Firefox/12.0a1 ID:20120118122712
Bad:
http://hg.mozilla.org/mozilla-central/rev/f76b576a9e28
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120119 Firefox/12.0a1 ID:20120119023512
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=58e933465c36&tochange=f76b576a9e28


Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/5a8bf51c8ede
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120118 Firefox/12.0a1 ID:20120118111412
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/6435f51dd10d
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120118 Firefox/12.0a1 ID:20120118121914
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5a8bf51c8ede&tochange=6435f51dd10d


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
Status: UNCONFIRMED → NEW
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:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/generic/nsFrame.cpp&rev=3.610&root=/cvsroot#963
Severity: normal → minor
Component: Layout → Layout: Tables
Attached patch fix (obsolete) — Splinter Review
https://tbpl.mozilla.org/?tree=Try&rev=ac2128116662
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:
http://www.w3.org/TR/css3-box/#overflow

Unlike what our style system says:
http://mxr.mozilla.org/mozilla-central/source/layout/style/nsRuleNode.cpp#4762

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:
> http://www.w3.org/TR/css3-box/#overflow

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:
> http://mxr.mozilla.org/mozilla-central/source/layout/style/nsRuleNode.
> 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:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e3da600d7642
Status: NEW → RESOLVED
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.