New issue
Advanced search Search tips

Issue 918889 link

Starred by 4 users

Issue metadata

Status: WontFix
Owner:
Closed: Jan 4
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Absolutely positioned div conflicting with contain layout in Chrome 71

Reported by bra...@ionic.io, Jan 3

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce the problem:
I created a reduced Codepen example here: https://codepen.io/brandyscarney/pen/bOgmvW?editors=1100

1. Open the Codepen above
2. See that the circular button on the right is behind the header
3. Comment out / remove one of the following lines in the CSS section:

```
/* commenting the below line resolves the problem */
z-index: 10;
```

or

```
/* commenting the below line resolves the problem */
contain: layout;
```

4. See the button appear on top of the header.

This issue did not exist prior to Chrome 71, and it is working without commenting anything out in Firefox and Safari (both tested on a Mac).

This is also visible in our demo on our documentation site here: https://ionicframework.com/docs/components/#fabs

What is the expected behavior?
The button (z-index: 999) should appear on top of the header (z-index: 10) when the contain property set.

What went wrong?
With the update to Chrome 71, the button is now displaying behind the header.

Did this work before? Yes 70

Does this work in other browsers? Yes

Chrome version: 71.0.3578.98  Channel: stable
OS Version: OS X 10.12.6
Flash Version: 

I am not sure if this is a bug or if it is a code issue that will eventually break in all browsers, so my apologies if it is on us.
 
Labels: Needs-Bisect Needs-Triage-M71
Cc: vamshi.kommuri@chromium.org
Labels: -Pri-2 -Needs-Bisect hasbisect-per-revision ReleaseBlock-Stable Triaged-ET Target-71 Target-72 Target-73 M-71 RegressedIn-71 FoundIn-71 FoundIn-73 FoundIn-72 OS-Linux OS-Windows Pri-1
Owner: r...@igalia.com
Status: Assigned (was: Unconfirmed)
Thanks for filing the issue!

Able to reproduce the issue on reported chrome version 71.0.3578.98 and on the latest canary 73.0.3659.0 using Mac 10.14.1, Ubuntu 14.04 and Windows 10.

Bisect Information:
-------------------
Good Build: 71.0.3545.0
Bad Build:  71.0.3546.0

You are probably looking for a change made after 589688 (known good), but no later than 589689 (first known bad).
CHANGELOG URL:  https://chromium.googlesource.com/chromium/src/+log/f3fd321621a946f69068fa5d50dc0c9c505a6bab..f01f396190da97d7218ee2f5d76b6b637bf3ced2
Suspecting: https://chromium.googlesource.com/chromium/src/+/f01f396190da97d7218ee2f5d76b6b637bf3ced2
Review URL: https://chromium-review.googlesource.com/1211922

@Manuel Rego Casasnovas: Please help in assigning it to the right owner if this isn't related to your change.

Thanks!





Status: WontFix (was: Assigned)
I believe the current behavior in Chromium is right.
Notice that if you enable "layout.css.contain.enabled" flag in Firefox, the behavior is the same there.
Safari doesn't implement css-contain yet, so it's not unexpected that the behavior is different in that case.

The spec is very clear, if you use "contain: layout" (https://drafts.csswg.org/css-contain/#containment-layout):
"5. The element creates a stacking context."

A possible solution could be setting for example "z-index: 20" on that element.
Thank you for the responses! Unfortunately we can't add `z-index: 20` on the parent content which has the contain as we need all other content to be able to scroll behind the header. However, if this is the correct behavior we will look into changing the structure or removing contain. Thanks!

Sign in to add a comment