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 124 users

Issue metadata

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

Sign in to add a comment

Issue 20574: Fixed-position element uses transformed ancestor as the container

Reported by, Aug 29 2009

Issue description

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

Chrome Version       : (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"
<html xmlns="">
<meta http-equiv="content-type" content="text/html; charset=utf-8" />

<style type="text/css">
	#fixed {position:fixed ; top:0 ; left:0 ; width:500px ; height:500px ;
overflow:hidden ; background-color:#ccc}
	#img {position:absolute ; bottom:100px ; right:0 ;
	#ruler {position:absolute ; top:0 ; left:500px ; width:100px ;
height:500px ; background-color:#666}


<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="" />
<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 />

Comment 1 by, Sep 3 2009

Labels: -Area-Misc Area-WebKit
Status: Untriaged
thanks for the report.

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

Comment 2 by, Oct 21 2009

Labels: Mstone-X

Comment 3 by, 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.

Comment 4 by, Sep 5 2012

Guys, what about this issue, 2013 year is coming but "position: fixed" still do not cope with transform value...

Comment 5 by, 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, Sep 27 2012

CSS3 transitions of any type seem to trigger this issue as well, causing position:fixed elements to render incorrectly.

Comment 7 by, Nov 29 2012

In (jamesr): 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:

Comment 8 by, Nov 29 2012


Comment 9 by, Feb 15 2013


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.

Comment 10 by, Feb 15 2013

I think the bug 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 ccing who is the owner of the feature in WebKit.

Comment 11 by, Mar 10 2013

Project Member
Labels: -Area-WebKit Cr-Content

Comment 12 by, Apr 6 2013

Project Member
Labels: -Cr-Content Cr-Blink

Comment 13 by, Sep 11 2013

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.

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

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

Comment 16 by, Nov 20 2013

Chromium dev team, need to raise the priority and label it to Cr-Blink-CSS, like done to

Comment 17 by, Jan 2 2014

I can still reproduce the bug in jsfiddle:

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

yep, me too:

if you uncomment the -webkit-transform part it works as it should be

Comment 19 by, Jan 2 2014

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:

Comment 20 by, Jan 2 2014

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:

So maybe we should open a discussion on w3c or whatwg?

Comment 21 by, Jul 25 2014

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.

Comment 22 by, Jul 30 2014

Is anyone attempting to fix this issue?

Comment 23 by, Aug 9 2014

This still exists (after 5 years!) and is causing issue with my homepage,, that don't exist in IE. Is this still a non-issue to Google?


Comparisons attached (IE 11 vs FF 34, Chrome 38)
Screenshot (238; cropped).png
111 KB View Download

Comment 24 by, Aug 11 2014

Please note that this is still an unresolved issue in standards ( 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, 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!

Comment 27 by, Jan 7 2015

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

Comment 28 by, Jan 7 2015

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

Comment 32 by, Feb 23 2015

This behavior conforms to the current W3C spec. If you think the spec is wrong, please comment

Comment 33 by, Mar 19 2015

this seriously needs to be fixed.

Comment 34 by, 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.>>

Comment 35 by, Mar 19 2015


Though I am merely a web developer and not a chromium developer, it is obvious, based on what the 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 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.


Comment 36 by, Mar 19 2015

#27 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*/


Comment 37 by, Mar 19 2015


Comment 38 by, Mar 19 2015

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, 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

- Chrome (41.0.2272.89 m (64-bit))Updated
- Opera (28.0.1750.48) Stable updated 

- Firefox (36.0.1) updated
- IE11 (11.0.9600.17501) updated up to 11.0.15

Comment 40 Deleted

Comment 41 by, Mar 19 2015

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, 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):

I think they use something similar what I have found also in this web, point 4 (#4 – Meet the :target pseudo selector):

But I have simplified and modified the code of 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;


.lightbox-target:target {
    opacity: 1;
    top: 50%;
    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

Comment 43 by, Mar 20 2015

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:

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

Comment 44 by, Mar 20 2015

Yes, I also think this could be different, I think could be related with the anchor href="#". I almost reproduce it:

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

Comment 45 by, Mar 20 2015

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.

Comment 47 by, Nov 2 2015

 Issue 470452  has been merged into this issue.

Comment 48 by, Nov 2 2015

 Issue 129405  has been merged into this issue.

Comment 49 by, Dec 3 2015

 Issue 268976  has been merged into this issue.

Comment 50 by, 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, Jul 15 2016

I encountered this issue when using React material-ui:

Comment 52 by, 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:

Comment 53 by, Oct 29 2016

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

Comment 54 by, Dec 12 2016

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


Of course, the desired behavior is that the `left/top` attributes will be relative to the topmost viewport and not closest one, on fixpos.

Comment 55 by, Dec 12 2016


Comment 56 by, Oct 25 2017

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.

Comment 57 by, Oct 26 2017

Components: -Blink Blink>Layout
Labels: -mstone-X Hotlist-Interop
Status: Untriaged (was: WontFix)
Re #56 Please also see

... 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 tracks it.

I just noticed that the draft css-transforms-2 ( 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, Oct 30 2017

Status: Available (was: Untriaged)

Comment 59 by, Nov 5 2017

Is there a test case in this bug that fails in Chrome but passes in Edge and/or FF? I can't find one.

Comment 60 by, Nov 5 2017

Please see It "fails" on all browsers except IE/Edge.

Because fixing this bug will change Web API, I think we need to follow

Comment 61 by, Nov 5 2017

Description: Show this description

Comment 62 by, Nov 6 2017

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.

Comment 63 by, Nov 6 2017

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 to track.

Comment 64 by, Nov 15 2017

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

Comment 65 by, Sep 29

FYI, this issue also causes incorrect positioning of video download button when a <video> tag is placed inside a CSS-transform'ed element (see a screenshot attached).

This is because internally Chrome uses fixed positioning for this button (or rather for the popup menu the button is in).
video download button.jpg
17.7 KB View Download

Sign in to add a comment