785684 - div content not clipped when display=table-cell

Status: RESOLVED WONTFIX

(Core :: Layout: Tables, defect)

Description

[eugene]

Attachment: 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

Comment 1

[Alice0775 White]

Attachment: 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

Comment 2

[Mats Palmgren (inactive)]

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.

Comment 3

[Mats Palmgren (inactive)]

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

Comment 4

[Mats Palmgren (inactive)]

Attachment: fix

https://tbpl.mozilla.org/?tree=Try&rev=ac2128116662

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 6

[Mats Palmgren (inactive)]

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.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(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.)

Comment 8

[Mats Palmgren (inactive)]

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.

Comment 9

[Mats Palmgren (inactive)]

Landed reftests that pass with the current rendering:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e3da600d7642

Comment 10

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/e3da600d7642