876341 - backface-visibility:hidden on the body makes position:fixed not be fixed

Status: NEW

(Core :: Web Painting, defect)

Description

[Sean Bullock]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Firefox/21.0 (Beta/Release)
Build ID: 20130511120803

Steps to reproduce:

Applied backface-visibility:hidden; or -moz-backface-visibility:hidden; to the body tag in CSS.


Actual results:

Any elements that were position:fixed; were treated like position:absolute; instead.


Expected results:

It should have removed flickering glitches with animations in the same way that webkit does.

Comment 1

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

Hmmm.  The transforms spec says that elements with 'transform' set to other than 'none' should act as containers for 'position:fixed' elements rather than having them attach to the viewport.  But it doesn't explicitly say the same about backface-visibility.  I wonder whether our behavior here is intentional.

Comment 2

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

Code-wise, nsCSSFrameConstructor calls nsStyleDisplay::HasTransform for making the relevant determinations.

HasTransform has returned true for backface-visibility since https://hg.mozilla.org/mozilla-central/rev/f621a747531a .

(The frame constructor has called HasTransform since long before that, https://hg.mozilla.org/mozilla-central/rev/b827e694565d and https://hg.mozilla.org/mozilla-central/rev/1fb56a23792d .)

I suspect the change in this context was unintentional, but I'm curious what mattwoodrow thinks.

Comment 3

[Matt Woodrow (:mattwoodrow)]

Yes, this was unintentional, but it's not clear what behaviour is expected by the spec.

Bug 730166 changed backface-visibility:hidden frames to be treated as transformed to get parity with WebKit.

The case being fixed was where we had a preserve-3d parent with a rotation transform (such that we would be seeing the 'back' face of child elements). One of the children had backface-visibility:hidden, and this wasn't being applied since we weren't treating that frame as transformed.

From the spec: "The ‘backface-visibility’ property determines whether or not the "back" side of a transformed element is visible when facing the viewer."

It's not clear to me what actually defines a transformed element, but it would make sense to include the children of preserve-3d elements. I'm not sure if these frames should also be treated as a stacking context/containing block.

Having backface-visibility:hidden frames that aren't part of a preserve-3d group is definitely a bug though.

Comment 4

[Vesa Piittinen]

I guess this might be a too highly opionated comment, but I think you shouldn't change the "viewport" of any fixed positioned element. By now everybody expects fixed to work like it always has and consider it reliable to place fixed overlays and generate modal dialogs using fixed elements. This feature breaks this behavior with a single property in the wrong place.

Worst thing is that they do use this property and transforms in general to fix iPad and iOS WebKit issues with animations. Of course the usage is incorrect as seemingly totally unrelated CSS property is used to fix things with those. This isn't directly related to the issue, but does contribute into it: there are templates and plugins provided that set this property into a container element.

IE team has chosen not to change fixed behavior with transforms and I think this is one case where they are right. Keep the existing behavior and don't add more confusion. If the spec is unclear then it is atleast better not to mess things up.

WebKit does not let backface-visibility: hidden; alone to do anything, you also need to pair it with a transform for anything to happen. This is slightly better, but I still find it too dangerous.

Comment 5

[trespassersW]

Attachment: backface-visibility & fixed position

body { backface-visibility: hidden }

Comment 6

[Kolya]

I agree with Vesa Piittinen, backface-visibility alone should not change fixed behaviour. If the spec is unclear it's better not to do anything than something unexpected. Firefox is still alone with this way.