New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 123 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Nov 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

Fixed-position element uses transformed ancestor as the container

Reported by hkyu...@gmail.com, Aug 29 2009

Issue description

(Update by wangxianzhu:
 - Test case: http://jsbin.com/ciyegab.
 - The original test case below "succeeds" on firefox because firefox doesn't support -webkit-transform.)

Chrome Version       : 4.0.202.0 (build 23673)
URLs (if applicable) :
Other browsers tested:
     Safari 4:FAIL
  Firefox 3.x:OK


==========================

I am bad at English.

test below

(scroll down)


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />

<style type="text/css">
	/*<![CDATA[*/
	#fixed {position:fixed ; top:0 ; left:0 ; width:500px ; height:500px ;
overflow:hidden ; background-color:#ccc}
	#img {position:absolute ; bottom:100px ; right:0 ;
-webkit-transform:scale(0.5)}
	#ruler {position:absolute ; top:0 ; left:500px ; width:100px ;
height:500px ; background-color:#666}
	/*]]>*/
</style>

</head>

<body>
<div id="fixed">
parentNode<br />
- <b>position:fixed</b> ;<br />
- <b>overflow:hidden</b> ;<br />
childNode<br />
- <b>-webkit-transform:rotate(180deg)</b>
<img id="img" src="http://img0.gmodules.com/ig/images/korea/logo.gif" />
</div>
<div id="ruler"></div>
<br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br
/><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br
/><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br
/><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br
/><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br
/><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br
/><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br
/><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br
/><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br
/><br /><br /><br />
</body>
</html>
 
Labels: -Area-Misc Area-WebKit
Status: Untriaged
thanks for the report.

confirmed that Chrome/Safari behaves differently than IE/FF/Opera, marking for further 
review...

Comment 2 by karen@chromium.org, Oct 21 2009

Labels: Mstone-X

Comment 3 by kerz@chromium.org, Jul 8 2010

Status: Available
Moving all bugs marked as untriaged and mstone X to be available rather than untriaged.  If you think this is in error, please feel free to set back to untriaged.
Guys, what about this issue, 2013 year is coming but "position: fixed" still do not cope with transform value...

Comment 5 by hac...@gmail.com, Sep 21 2012

I just ran into this bug myself and went half way nuts cause I thought I had a bug in my Dart code.

Comment 6 by davvbl...@gmail.com, Sep 27 2012

CSS3 transitions of any type seem to trigger this issue as well, causing position:fixed elements to render incorrectly.
Cc: skyos...@chromium.org jam...@chromium.org
In https://bugs.webkit.org/show_bug.cgi?id=103470#c1 (jamesr):

http://dev.w3.org/csswg/css3-transforms/#transform-rendering says:

For elements whose layout is governed by the CSS box model, any value other than ‘none’ for the transform results in the creation of both a stacking context and a containing block. The object acts as a containing block for fixed positioned descendants.

NOTE: Is this effect on position:fixed necessary? If so, need to go into more detail here about why fixed positioned objects should do this, i.e., that it's much harder to implement otherwise. See  Bug 16328 .

Related bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328

Cc: wangxianzhu@chromium.org
@wangxianzhu

seems that the fix is necessary, 'cause for example FF copes with it perfectly.
transforming of fixed elements is needed in a lot of cases of implementing some useful interaction effects etc.
I think the bug w3.org needs to be fixed first. The standard must be agreed upon before we change the current behavior. The related code is in WebKit, feel free to file a bug on bugs.webkit.org ccing simon.fraser@apple.com who is the owner of the feature in WebKit.
Project Member

Comment 11 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-WebKit Cr-Content
Project Member

Comment 12 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink
My English is bad, but with the help of a translator friend, here we go:

If you exceed any limit side of its parent element that has a fixed position find the bug.

ex:
<div style="position:fixed;width:100px;height:100px;top:0;left:0;display:block">
<span style="text-indent:-99999px;"> fafa </ span>
</ div>

BUG!
Because the text-indent exceeds the limits of its box-sizing.

Comment 14 Deleted

Comment 15 by Deleted ...@, Nov 20 2013

Definitely a bug, not sure if there is a workaround other than remove transforms, but frustratingly I am only using these to fix the 3dtranform flicker bug. Would love it if someone could fix these bugs :-)
Chromium dev team, need to raise the priority and label it to Cr-Blink-CSS, like done to https://code.google.com/p/chromium/issues/detail?id=124331

Comment 17 by vojt...@knyt.tl, Jan 2 2014

I can still reproduce the bug in jsfiddle:
http://jsfiddle.net/p3x2K/

Comment 18 by Deleted ...@, Jan 2 2014

yep, me too: http://jsfiddle.net/6y6pS/3/

if you uncomment the -webkit-transform part it works as it should be
Yes nice example to reproduce the issue. I updated the div text in order to make it more readable to who tries to reproduce it: http://jsfiddle.net/rastrano/2PNFy/
Anyway sadly this is not a Chromium bug, but also latest version of FF and Opera now have it! 

I did a little research and i discovered why with this article, that explains that this is what is in the specs:

http://meyerweb.com/eric/thoughts/2011/09/12/un-fixing-fixed-elements-with-css-transforms/

So maybe we should open a discussion on w3c or whatwg?
Read this thread today and found elsewhere that if you add -webkit-transform: translateZ(0); to your element that you want to act as position fixed it seems to make it act correctly. Here's where i found the answer.

http://stackoverflow.com/questions/20503424/positionfixed-not-working-in-google-chrome
Is anyone attempting to fix this issue? 
This still exists (after 5 years!) and is causing issue with my homepage, http://BHStudios.org, that don't exist in IE. Is this still a non-issue to Google?

SSCCE: http://jsfiddle.net/Supuhstar/t04nh943/

Comparisons attached (IE 11 vs FF 34, Chrome 38)
Screenshot (238; cropped).png
111 KB View Download
Please note that this is still an unresolved issue in standards (https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328). We would rather not change the current behavior until the standard makes clear how the browsers should exactly behave against the case.

Comment 25 by 3leve...@gmail.com, Nov 11 2014

I am also seeing this behaviour when embedding a map via the Google Maps API. When the page loads, the text in my position: fixed elements are crisp and clear however, after the Google Map <div> is rendered, I assume it is the -webkit-transform: translateZ(0px); which causes the text in position:fixed elements to re-render causing a general blurry/fuzzy appearance. This also affect the color of the text due to the spread.

Comment 26 by Deleted ...@, Dec 22 2014

This bug is still exist after FIVE years!
Status: WontFix
Because FF/Opera/Safari/Chrome behave the same, I think we should keep the behavior. This behavior conforms to the current W3C specification http://dev.w3.org/csswg/css-transforms-1/#transform-rendering. Though there is a W3C pending bug about the behavior, for now we need to conform to the spec until W3C decided to change the spec.
The link to the spec should be http://dev.w3.org/csswg/css-transforms/#transform-rendering.

Comment 29 by Deleted ...@, Feb 1 2015

this is ridiculous, why this bug is still not fixed? I can't find any workaround rather than using ajax javascript to position the element.

Comment 30 by Deleted ...@, Feb 19 2015

Wont' fix? Are you serius? Let me explain this bug since it seems to be out of your grasp:

1) Fixed element works like fixed element
2) Add non-related transform anywhere higher up in the DOM-tree
3) Fixed element starts behaving like it is static in Chrome and has been for the last five years (_not_ in FF and _not_ in Safari on IOS)

Please explain how this is "behavior" not a Chrome bug.

Comment 31 Deleted

This behavior conforms to the current W3C spec. If you think the spec is wrong, please comment https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328.
this seriously needs to be fixed.

Comment 34 by tvr...@gmail.com, Mar 19 2015

It is easy to understand, for clear minds, a fixed element: "Position:fixed-->The element is positioned relative to the browser window".

So if you do that in Firefox and IE: WORKS, the background doesn't move.

You do that in Chrome and Opera: DOES NOT WORK, the background moves and jumps.

Who are the browsers that fails?: CHROME AND OPERA. 

Who are the browsers that need to fix the bug?: Easy again, CHROME AND OPERA.

You have to keep in mind users, not any organization... << "Interesting, though elementary," said he as he returned to his favourite corner of the settee.>>
* * * READ BEFORE POSTING * * *

Though I am merely a web developer and not a chromium developer, it is obvious, based on what the chromium.org people have very *patiently* tried to explain to the ranting and raving masses (who obviously DO NOT GET IT), that this is NOT a bug with Chromium. It is a bug with the w3c spec.

I would thus advise people who would OTHERWISE POST INFANTILE / NON-CONSTRUCTIVE / MISGUIDED COMMENTS (which otherwise have started flooding my inbox in record numbers from this thread), to instead not post anything in this thread, and instead please comment at https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328 as per wangxianzhu's suggestion.

If people keep on blindly posting without reading, devs will (very rightfully) restrict comments on this page (such as potential future workarounds), which would be sad. Thank you for stopping to read and think before speaking.

* * * READ BEFORE POSTING * * *

Comment 36 by tvr...@gmail.com, Mar 19 2015

 #27 wangxianzhu@chromium.org said:
"Though there is a W3C pending bug about the behavior, for now we need to conform to the spec until W3C decided to change the spec."

First of all sorry for my english, I try to explain why I think wangxianzhu is wrong. He said that, ok, we are based in W3C spec's, and until the W3C don't say nothing about their bug we don't change nothing. Yes, but you know that the specs have a bug and that due to that bug your browser (in this case) could be failing, so try to fix it (as I think other teams probably have done in Firefox and Microsoft) and try to solve the problem that is affecting some developers (and by the way users) instead of wait that W3C decide something to do because you could wait for a long time...

I hope W3C solve or change the specs for this as soon as they can.

I have found this for people who could need it, add this to your fixed element CSS, for me doesn't work:
transform: translateZ(0);
    -moz-transform: translatez(0);
    -ms-transform: translatez(0);
    -o-transform: translatez(0);
    -webkit-transform: translateZ(0);
    -webkit-font-smoothing: antialiased; /* seems to do the same in Safari Family of Browsers*/


Regards
Cc: pdr@chromium.org chrishtr@chromium.org esprehn@chromium.org jchaffraix@chromium.org
http://jsbin.com/xizedefupa

Browsers conforming to the current spec:
- Safari (7.1.3) on Mac (not tested on other platforms)
- FireFox (36.0.1) on Linux (not tested on other platforms)
- Chrome (all version) on all platforms
- Opera (28.0) on Mac (not tested on other platforms)

Only browser I tested not conforming to the current spec:
- IE (10.0.9200.17183)

Anyone who tested FireFox and Safari resulting the IE behavior please provide the versions and platform you tested.

Comment 39 by tvr...@gmail.com, Mar 19 2015

If we are talking about the same problem (fix an element, a lightbox markup, with 'position: fixed' but the background moves (conforming current spec) instead of don't do it (not conforming the current spec-->correct way) when you open that overlay) this happens to me in the next browsers:

PLATFORM IN ALL BROWSERS: Windows 7 Ultimate 64 bits

CONFORMING SPEC (WRONG WAY):
============================
- Chrome (41.0.2272.89 m (64-bit))Updated
- Opera (28.0.1750.48) Stable updated 

NOT CONFORMING SPEC (CORRECT WAY):
==================================
- Firefox (36.0.1) updated
- IE11 (11.0.9600.17501) updated up to 11.0.15

Comment 40 Deleted

Which test case and platform did you use to test Firefox? For my test case (and several other test cases linked from this bug), my FireFox 36.0.1 on Linux/Mac behaves the same as Chrome/Opera/Safari.

Note, for some test cases that use -webkit-transform on the container, FireFox doesn't behave the same as Chrome. This is because FireFox ignores the webkit-specific property -webkit-transform. FireFox will behave like Chrome if you change the property to '-moz-transform' or just 'transform'.

About which behavior is correct, please discuss it in the w3c bug instead. In addition, I think the w3c bug doesn't mean the behavior is wrong. It means the spec needs to be more clear about the behavior.

Comment 42 by tvr...@gmail.com, Mar 20 2015

Hi wangxianzhu,

 I'm creating a webpage modifying a bootstrap 3 responsive template. The platform is Win 7 64 bits. FireFox 36.0.1

 As I need to create a lightbox to show some text I've used the example of this page (seems site does not working now): http://www.designcouch.com/home/why/2013/11/01/responsive-css3-lightbox-with-no-javascript/

I think they use something similar what I have found also in this web, point 4 (#4 – Meet the :target pseudo selector):
http://modernweb.com/2014/07/30/5-things-wont-believe-built-css/

But I have simplified and modified the code of www.designcouch.com just only to this:

.lightbox-target {
     position: fixed;
     transform: translateZ(0);
    -moz-transform: translatez(0);
    -ms-transform: translatez(0);
    -o-transform: translatez(0);
    -webkit-transform: translateZ(0);
    -webkit-font-smoothing: antialiased; /* seems to do the same in Safari Family of Browsers*/
    z-index: 9999;
    opacity: 0;
    -webkit-transition: opacity .5s ease-in-out;
    -moz-transition: opacity .5s ease-in-out;
    -o-transition: opacity .5s ease-in-out;
    transition: opacity .5s ease-in-out;
    overflow: hidden;
    padding: 2% 4% 2% 4%;
    box-shadow: 0px 0px 8px #337ab7;
    background: #5bc0de;
}

and

.lightbox-target:target {
    opacity: 1;
    top: 50%;
    left:50%;
    width:80%;
    transform: translate(-50%,-50%); /* This is a shorthand of translateX(-50%) and translateY(-50%) */
    -khtml-transform: translate(-50%,-50%);
    -moz-transform: translate(-50%,-50%);
    -webkit-transform: translate(-50%,-50%);
}

When I click on the icon in the web that launchs the lightbox works fine as I said in Firefox and IE but not in Chrome and Opera
Summary: Fixed-position element uses transformed ancestor as the container (was: rendering bug : position:fixed AND -webkit-transform)
tvraul, thanks for the info. According to it, I created a jsbin page: http://jsbin.com/sovarayapi.

However, the page looks to me the same in all browsers perhaps because I missed something. Please feel free to modify the page so that it can reproduce the issue, or just upload your test case. Please also describe the steps to reproduce the issue and the expected and actual results. I'm not sure I understand your description in #34, e.g. what do you mean the 'background' in your description 'the background moves and jumps'?

Anyway, I think your issue is not the same as the issue that we don't want to fix. We would file another bug for your issue after we confirm it. I have modified the summary of this issue to be more accurate. It's about that a fixed-position element as a descendant of a transformed element uses the transformed element as the container instead of the viewport (as specified in http://dev.w3.org/csswg/css-transforms/#transform-rendering).

Comment 44 by tvr...@gmail.com, Mar 20 2015

Yes, I also think this could be different, I think could be related with the anchor href="#". I almost reproduce it:
http://jsbin.com/dilawotola/5/

In the jsbin you can see the jump when click on close, the page goes to the top instead of doesn't move. 

In my example the jump is different. If you are in the top of the page and you click to open the lightbox what happens (in Chrome) is that the page jumps to the end of the page, show you the lightbox-target, and when you close it then returns to the top. But as position of the lightbox is position:fixed should only consider the viewport, I think, not where is in the DOM the lightbox or where the href points.

In Firefox and IE wherever you are, the lightbox opens without move the background of the lightbox and when you close it the background is in the same position, without any type of move.

Here could be more info that I just already find it, but I don't have time to check all, too difficult this problem for me, I'm not an expert!:
http://stackoverflow.com/questions/6794000/fixed-position-but-relative-to-container
Thanks for the test case. Filed  bug 469243 .

Comment 46 by Deleted ...@, May 14 2015

I had this bug and fixed it by using translate3d(-100%, 0, 0) instead of translateX(-100%) and it worked.
Cc: tkonch...@chromium.org
 Issue 470452  has been merged into this issue.
 Issue 129405  has been merged into this issue.
Cc: nyerramilli@chromium.org
 Issue 268976  has been merged into this issue.

Comment 50 by zi...@zixia.net, Feb 16 2016

I use angular-material in a google spreadsheets' add-on, which means "transform: translate3d(...);" run inside google spreadsheet, a iframe.

I used a form input element, which has a animate 'label' tag. then I got a scrollbar in the iframe, it's quite hard to debug, at last I found if I delete the css setting of "transform" on 'label' tag, the scrollbar's gone.

I believe it is caused by this issue: 'transform' has side effect to other containters, which cause position error.

so at last, I had to hard coded a css style code in my html header: "transform: none !important;" (I lost animate of my input label).

Comment 51 by myai...@gmail.com, Jul 15 2016

I encountered this issue when using React material-ui: https://github.com/callemall/material-ui/issues/3494.

Comment 52 by oria...@gmail.com, Sep 15 2016

I agree with W3 compliance. However this is a very clear bug in spec, and a workaround is needed for the time being. 
Mobile web and responsive design is more common these days, and so is the use of transform:scale, making this marginal bug to a more major issue. Just one of many examples: sticky headers on a scaled table is currently impossible. We've been waiting a long time for the position property to be fixed (see what I did there?) by W3 but the issue was neglected.

In order to keep compliance with W3 while still offering a solution I suggest adding the following property:

-webkit-position-despite-transform: fixed|absolute|static|relative;

(Note that the property name is not more nor less ridiculous than the current behavior)

Please star and comment the W3 issue: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328#c14

Antediluvian bug! Will it be fixed before 2019? I bet NO.

http://codepen.io/lzl124631x/pen/LRKVXp

Comment 54 by oria...@gmail.com, Dec 12 2016

The `vh,vw` units are relative to the topmost viewport while the left/top attributes are relative to the closest viewport.

Reproduce:
https://jsfiddle.net/oriadam/otex3kp2/


Of course, the desired behavior is that the `left/top` attributes will be relative to the topmost viewport and not closest one, on fixpos.
Cc: -wangxianzhu@chromium.org
I understand that transforming an element establishes a new local coordinate system, but according to the spec for fixed positioning, it's explicitly stated that the containing block is established by the viewport. https://drafts.csswg.org/css-position-3/#fixed-pos
Cc: -jchaffraix@chromium.org -esprehn@chromium.org -jam...@chromium.org tabatkins@chromium.org
Components: -Blink Blink>Layout
Labels: -mstone-X Hotlist-Interop
Status: Untriaged (was: WontFix)
Re #56 Please also see http://dev.w3.org/csswg/css-transforms/#transform-rendering:

... transform also causes the element to become a containing block, and the object acts as a containing block for fixed positioned descendants.

The two specs are inconsistent, and https://github.com/w3c/csswg-drafts/issues/913 tracks it.

I just noticed that the draft css-transforms-2 (http://dev.w3.org/csswg/css-transforms-2/#transform-rendering) deleted the mentioning of fixed position, so I think it's time to reopen this bug and track changes of the spec.

Comment 58 by e...@chromium.org, Oct 30 2017

Cc: ikilpatrick@chromium.org e...@chromium.org
Status: Available (was: Untriaged)
Cc: robho...@gmail.com
Is there a test case in this bug that fails in Chrome but passes in Edge and/or FF? I can't find one.
Please see http://jsbin.com/ciyegab. It "fails" on all browsers except IE/Edge.

Because fixing this bug will change Web API, I think we need to follow https://www.chromium.org/blink#TOC-Web-Platform-Changes:-Process.
Description: Show this description
I don't think we should change behavior here. Instead if necessary we should
adjust the spec to match Chrome's current behavior. Trying to let fixed-position
elements escape a transform will cause a lot of weird complications and leads to ill-
defined compositing.
Status: WontFix (was: Available)
I spoke with the transforms spec editor (@smfr) and we agree that the
css-transforms-1 requirement should carry over to css-tranforms-2.
Filed https://github.com/w3c/csswg-drafts/issues/1945 to track.
Note that this is one of the issues on our list of interop problems that caused real-world pain for the search team.  Googlers can see the impacted code at https://goto.google.com/gws-transform-issue.

Sign in to add a comment