env() is implemented, but the safe-area-inset-* variables aren’t, and this completely breaks sites that use them
Reported by
chris.mo...@gmail.com,
Jul 6
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0 Example URL: https://www.fastmail.com/login/ Steps to reproduce the problem: Here is a sample document, a very slightly simplified version of what is used at the time of writing on the FastMail app: <!doctype html> <style> html, body { height: 100%; } .app { position: absolute; top: 0; bottom: 0; left: 0; left: env(safe-area-inset-left); right: 0; right: env(safe-area-inset-right); background: red; } </style> <div class=app> <h1>Hi!</h1> </div> What is the expected behavior? The entire page should have a red background. What went wrong? The red background only spans the width of the heading, because the `left` and `right` properties have been messed up. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 69.0.3482.0 (Official Build) canary (64-bit) (cohort: Clang-64) Channel: canary OS Version: 10.0 Flash Version: Because the env() function is supported, `left: env(safe-area-inset-left)` overrides `left: 0` (same for `right`); but the safe-area-inset-left environment variable then isn’t defined, and so it is as though `left: unset` had been used. This could be worked around on websites by using a fallback value, env(safe-area-inset-left, 0), but most people using it already won’t have those fallbacks, because they aren’t supposed to be needed. The CSS Environment Variables Module Level 1 draft specification (https://drafts.csswg.org/css-env-1/) explicitly defines four environment variables that “must be supported”: safe-area-inset-top, safe-area-inset-right, safe-area-inset-bottom and safe-area-inset-left. Chrome seems to have implemented env() without having implemented them. This leads to sites that use the environment variables but don’t specify a fallback—which is going to be most, I think, since it’s not required in Safari—breaking completely. See also Issue 855134 which is slightly related. I believe this is a blocker to shipping env().
,
Jul 6
,
Jul 6
FWIW we do actually support the safe-area-inset variables. However, they are only enabled on Android so this is why they are not being picked up on other platforms. The spec mentions a default value for the inset variables so I think it should be reasonable to set these to the default on the other platforms.
,
Jul 8
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/817ca3d4d1ddf5e8571bb79eccf8d73f6efa65c3 commit 817ca3d4d1ddf5e8571bb79eccf8d73f6efa65c3 Author: Becca Hughes <beccahughes@chromium.org> Date: Sun Jul 08 06:10:07 2018 [CSS Env Vars] Set default env() vars At the moment we only set the safe-area-inset-* variables on Android which is causing some bugs on sites. This CL sets a default value of 0px for all the variables. BUG= 860604 Change-Id: I204378cfeabe95cb531776b6e7bb78b601526b89 Reviewed-on: https://chromium-review.googlesource.com/1128050 Commit-Queue: Emil A Eklund <eae@chromium.org> Reviewed-by: Emil A Eklund <eae@chromium.org> Cr-Commit-Position: refs/heads/master@{#573182} [modify] https://crrev.com/817ca3d4d1ddf5e8571bb79eccf8d73f6efa65c3/third_party/blink/renderer/core/css/style_environment_variables.cc [modify] https://crrev.com/817ca3d4d1ddf5e8571bb79eccf8d73f6efa65c3/third_party/blink/renderer/core/css/style_environment_variables.h [modify] https://crrev.com/817ca3d4d1ddf5e8571bb79eccf8d73f6efa65c3/third_party/blink/renderer/core/css/style_environment_variables_test.cc
,
Jul 9
|
||||
►
Sign in to add a comment |
||||
Comment 1 by emilio@chromium.org
, Jul 6Components: -Blink Blink>CSS