760753 - 3D CSS animation causes scrollHeight to change

Status: RESOLVED INVALID

(Core :: Layout: Scrolling and Overflow, defect)

Description

[Gregg Tavares]

Attachment: css-animation.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20100101 Firefox/12.0
Build ID: 20120420145725

Steps to reproduce:

view the attached file, scroll to the bottom


Actual results:

firefox resizes the page constantly


Expected results:

the page should be a stable size? It is in Safari and Chrome. Of course it could be yet another CSS bug on my part.

Comment 1

[Kevin Brosnan [Ex-Mozilla]]

I see this on trunk as well.

Comment 2

[Alice0775 White]

Dup Bug 456497?

Comment 3

[Kevin Brosnan [Ex-Mozilla]]

Bug 456497 says that all the browser have the same behavior. This does not seem to be the case for this bug or that the data from 456497 comment 3 is dated.

Comment 4

[Gregory Pappas [:gregp]]

I can still reproduce this. Seems more like a layout thing so moving there. Also feel like this is a duplicate but I can't find anything.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (reduced somewhat, with scrollHeight-impacting 3D transform applied)

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 2 in Firefox vs. Chrome

Here's a screenshot showing the behavioral difference with testcase 2.

I don't have the transform css specs paged into my head right now, but a quick skim at
https://drafts.csswg.org/css-transforms-1
https://drafts.csswg.org/css-transforms-2
doesn't seem to really clarify what the expected outcome is here. To the extent that it is clear, it seems like maybe Firefox's behavior (creating scrollable overflow for the whole transformed element) is correct.

The only mention of "scrollable overflow" that I see is here:
https://drafts.csswg.org/css-transforms-1/#module-interactions

Transforms affect the computation of the scrollable overflow region

Unfortunately transforms-2 (which defines perspective and 3d transform stuff) doesn't mention scrollable overflow at all.

Comment 7

[Daniel Holbert [:dholbert]]

But yeah, transforms-1 pretty clearly says that we should create scrollbars to ensure that the transformed content is visible:

the extent of the overflow area takes into account transformed elements. This behavior is similar to what happens when elements are offset via relative positioning. Therefore, if the value of the overflow property is scroll or auto, scrollbars will appear as needed to see content that is transformed outside the visible area. Specifically, transforms can extend (but do not shrink) the size of the overflow area, which is computed as the union of the bounds of the elements before and after the application of transforms.

That's what we're doing (it's a little tricky to see in the original testcase since some of the content is transparent, but testcase 2 makes it clearer).

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: testcase 3

Here's a simpler testcase, using translate3d() with x, y, and z components.

It looks like the Z axis is where the behavior difference arises. As noted in the testcase, Firefox creates scrollbars to scroll all three of these scrollable areas (in the inline/block end direction) to be able to see the overflowing portion of the blue shape, far enough to reach the endwards lime border.

In other browsers, the scrollable overflow is not created in the 3rd box here.

Comment 9

[Daniel Holbert [:dholbert]]

I filed https://github.com/w3c/csswg-drafts/issues/8851 to seek clarification in the spec.

Comment 10

[Daniel Holbert [:dholbert]]

Per https://github.com/w3c/csswg-drafts/issues/8851#issuecomment-1552249496 on the spec issue, it sounds like Firefox is correct here, and Chromium folks consider their behavior to be a bug that should be fixed (in https://bugs.chromium.org/p/chromium/issues/detail?id=1264086 ).

--> Closing as INVALID, since it seems we're correct on this point.