Bug 160953 – WebKit incorrectly clips position:fixed element, inside of its "position:relative; overflow: hidden" parent, IF that parent has "z-index" set

• Status: NEW
• Component: Layout and Rendering

[Daniel Holbert]

STR:
 1. Load this testcase: https://jsfiddle.net/bo4q2hbh/

EXPECTED RESULTS:
 Teal div should not be clipped at orange border. (The teal div is a fixed-position element, and it should use the viewport as its containing block, rather than using its orange-bordered relpos ancestor.)

ACTUAL RESULTS:
 Teal div is clipped at orange border! (in Safari)

I get EXPECTED RESULTS in Firefox 48, Edge 14, and Chrome 54.
I get ACTUAL RESULTS in Safari 9.1 (on Mac OS El Capitan)

The bug only happens if the relatively-positioned ancestor has "z-index" set.  In my above-linked jsfiddle, that element has "z-index: 0". If I remove that line, the bug goes away and I end up with EXPECTED RESULTS.

Note: Chrome has a similar bug, but their bug is more restricted (it only happens if there's also 3d-transformed descendant).
https://bugs.chromium.org/p/chromium/issues/detail?id=638780

[Daniel Holbert]

Here's a reference case where I've removed "z-index: 0" from the parent:
  https://jsfiddle.net/bo4q2hbh/1/
This gives me EXPECTED RESULTS in Safari. There's no reason for that to have an effect on the rendering -- but it does, revealing that there's a bug here (in the rendering of the original testcase).

[Simon Fraser (smfr)]

Yeah, we don't clip position:fixed properly in some cases. See also bug 160886 which may be a dup.

[Daniel Holbert]

(In reply to comment #2)
> Yeah, we don't clip position:fixed properly in some cases. See also bug
> 160886 which may be a dup.

Thanks. This is causing at least one known interop issue, FWIW (a site accidentally depending on this incorrect clipping, and looking broken in Firefox & Edge as a result).  See https://github.com/webcompat/web-bugs/issues/3028 for details.

[Matt Rust]

Bug is still present in Version 10.1

One thing I noticed is it seems to be a painting issue. Buttons contained in the fixed element are still clickable. Also, inspecting the area where the fixed element should be works correctly.

https://codepen.io/anon/pen/rybaeZ

[Radar WebKit Bug Importer]

<rdar://problem/31463206>

[Mathieu HAYS]

Hi,

I've got a similar issue when the element being clipped is contained within another element having position:fixed and overflow:hidden.

Testcase: 
https://codepen.io/mathieuhays/pen/oWYvvm

Expected Result: 
The child element (with green background) should be visible on the right hand side.

Actual Result: 
The child element is not visible.

The above works on IE, Chrome, Firefox, Opera but not on Safari including the latest webkit nightly build. I've also tested the latest Safari on iPhone and the issue is reproducible there too.

[Stefan Seiz]

Created attachment 323520 [details]
Testcase

I have the same issue, even in Safari 11.0 (high sierra) as well as in Safari Technology preview.

In my testcase, you see a fullscreen image (background) with position fixed gets clipped by overflow hidden. If you view the testcase in Chrome, you'll see the image cover the whole browser window.

Very problematic, Chrome renders this correctly... adding CC.

[Raul G]

I am still having this problem on Safari 11.0.3. It seems to be working fine in every other browser. Also, as Matt Rust pointed, the buttons are still functional even though they are hidden.

I'm trying to figure out a proper workaround for this (without changing the whole layout) until the bug gets fixed. Did anyone solve this issue somehow?

[Brad]

This happens in iPhone Safari too, even without setting a z-index.

[Michael Prentice]

I'm seeing this in Safari 13.1 (15609.1.20.111.8) on macOS Catalina 10.15.4 (19E287).

Reproduction: https://stackblitz.com/edit/angular-material2-sidenav-issue-1dn1s1?file=src%2Fapp%2Fapp.component.html

This same example works correctly in Edge (Chromium), Chrome, and Firefox.

[Alan Fisher]

Did anyone find a workaround for this?

[miguel]

Ran into this issue in 2021, One way around this is to increase the height of the child where it is clipping on. I added a minHeight: '-webkit-fill-available' which seems to work well enough for now.

[Alan Fisher]

I found a simple solution that works:
https://stackoverflow.com/a/59656203/10600250

[Stefan Seiz]

It's great that Workarounds exist, i'd prefer this gets fixed though and am wondering if it's not about time.

[James Diacono]

The test cases above are resolved for me on the iOS 14.3 simulator, however I have a variant which still exhibits the issue:

https://codepen.io/diachedelic/pen/ExNgvYw

[Ahmad Saleem]

I am able to reproduce this bug in Safari 16 and Safari Technology Preview 154 and the background does not expand end to end and is containerised compared to Firefox Nightly 108 and Chrome Canary 107.

I know there are some z-index fixes in Webkit ToT so I will check with STP 155 and STP 156 again in future. Thanks!

[Peter Appleby]

Can still reproduce test case in Safari Version 16.5.2 (18615.2.9.11.10), removing the z-index on the fixed position child made the test case render correctly. Separately found an instance of this occurring without any z-indexes, will try and put together a minimal test case.

[Karl Dubost]

Maybe related to Bug 239418

[Ilya Konrad]

I can still reproduce it in a setup where an ancestor (A) has "overflow: hidden auto" (or "overflow-y: auto") with "position: relative", its deep descendant (B) has "position: absolute" with "z-index" and its deep descendant (C) has "position: fixed".

The "fixed" child block is clipped by the ancestor A for no reason, atrociously breaking the layout.

If I remove "position: relative" or the overflow rule from A - it works ok. The same is true if I remove "z-index" from B. However, obviously, I need all of them.

I checked a lot of provided examples of similar issues on real iPhone 13 (using Chrome, Safari and Firefox) and on Mac (using Safari and Chrome through Browserstack).

It seems to be an issue with all iOS devices and with Safari on Mac.

However only the example provided by Stefan (https://bugs.webkit.org/attachment.cgi?id=323520) has the same consistently broken behavior on different systems as my app.
Other examples (jsfiddles, codepens, etc.) work ok through Browserstack. Although maybe it's a Browserstack issue :/

Seems really critical, I'm surprised to see so few reports over all these years.

Is there a workaround? Is the bug being worked on? What can I do to help?

[Ilya Konrad]

I found a workaround. I leverage the new `:has()` selector to undo the CSS rules that trigger this bug when the cut off elements appear.
To only apply this madness in Webkit, I also added class `.webkit` using this condition `window.GestureEvent || window.navigator.userAgent.match(/iP(ad|od|hone)/i)`.

Here's my SCSS:

.webkit {
  // Fixes floating elements being cut-off by the sidebar when opened from a "position: absolute + z-index" element.
  main > .ns-dashboard {
    &:has(.requires-webkit-hack):has(app-overlay, app-popup, app-modal) {
      overflow: unset;
    }
  }

  .ns-page-header {
    // Fixes "add sub-groups" popup being cut-off by the sidebar.
    &:has(app-popup) {
      z-index: unset;
    }

    // Fixes group selector dropdown being cut-off by the sidebar on small screen.
    // This media query should match the query that adds `position: fixed` to `.ns-group-selector`.
    @media (max-width: variables.$screen-sm) {
      &:has(.ns-group-selector) {
        z-index: unset;
      }
    }
  }
}

Hope it helps someone to stay sane.

[JC Franco]

We encountered this issue in our components and created an additional test case to demonstrate it:

https://codepen.io/jcfranco/pen/rNgzLeL?editors=1010

Some suggested workarounds are not feasible for us due to the use of shadow DOM and external components.

The original testcase is not reproducible (i.e. works as EXPECTED) in Safari 17.5, however a slight modification where an intermediate statically position child is added between the relpos and the teal div:

.posrel > .static > .fixed

https://jsfiddle.net/z81ahequ/10/

After playing around a bit, it turns out that the bug is reproducible when the parent div has overflowing content, that is when the parent is actually scrollable. In the sandbox above, applying smaller width and height to .static "fixes" the bug. Changing `overflow: auto` to `overflow: hidden` also "fixes" the problem.

According to the Inspector, the .relpos becomes a separate layer because "Element has "-webkit-overflow-scrolling: touch" style", which apparently is added implicitly when the element can be scrolled.

More observations:

.relpos { z-index: 0; } + overflowing content => teal div clipped (BUG)
.relpos { /* no z-index */ } + overflowing content => teal div overflows (CORRECT)
.relpos { will-change: transform; /*and no z-index*/ } => teal div clipped even if there is no scroll in .relpos, however this seems CORRECT according to the spec as the .relpos becomes a containing block for the fixed element