Able to reproduce the issue on chrome reported version 69.0.3464.2 and on latest chrome 69.0.3468.0 using Mac 10.13.5, Ubuntu 14.04 and Windows-10. As this issue is seen from M-60(60.0.3112.0), hence considering this issue as Non-Regression and marking it as Untriaged.

Thanks!

This is also reproducible with var() so it looks like this is not specific to env().

Deleted: css_bug.html 883 bytes

css_bug.html 883 bytes View Download

This is a very serious issue that I expect is breaking pretty much everything that uses env(safe-area-inset-*) to some extent, though only some uses will be *completely* broken.

As an example, it’s breaking the FastMail app completely (you get a blank screen on Canary), as seen on https://www.fastmail.com/login/, due to this CSS (simplified slightly):

    .app {
        position: absolute;
        overflow: hidden;
        top: 0;
        bottom: 0;
        left: 0;
        left: env(safe-area-inset-left);
        right: 0;
        right: env(safe-area-inset-right);
    }

Chrome is implementing env() without having implemented safe-area-inset-* (which is itself a bug—the CSS Environment Variables Module Level 1 draft says they “are officially defined and must be supported”), and combined with this additional bug it ends up equivalent to `left: unset; right: unset`, which, given the layout techniques used inside, makes it zero width, and combined with `overflow: hidden` the end result is a completely blank page.

We could work around this bug by adding a `, 0` fallback to the env() calls, but we’d prefer to have this bug fixed.

#7: I don't see how that's related to this bug? This is about env() inside calc().

The behavior you describe is expected if a UA doesn't support a given environment variable. The right thing to do is using fallback fwiw, I'd think, though I guess Chrome will implement eventually the safe-area-* variables.

emilio: whoops, I was misled by the remark about “adding support for env() without adding support for any of the safe-area-inset-* variables”. My report is indeed another matter, that those variables are not implemented (which is quite a serious matter). I’ve filed the bug report I had initially written (before I erroneously decided that this was in fact a duplicate!) as  issue 860604 .

AFAICT, this is working as intended (assuming the environment variable isn't exposed - which we have  issue 860604  for now), although granted it may be non-obvious what is going on (and why.) What you should write here is:

padding-top: calc(env(safe-area-inset-top, 0px) + 20px);

The reason you can't have the unitless zero as a fallback (eventhough it would have worked "on its own" in the property) is because it appears within a calc(), and in such a context it is ambiguous - it will be parsed as a <number> and not a <length>. (See [1] - a note near the end of the section spells this out.)

So in your example you get:

calc(env(safe-area-inset-top, 0) + 20px) => [fallback] => calc(0 + 20px)

which is an invalid calc() expression. (I'd agree that these kind of "evaluation time" failures are not particularly nice and obvious...)

If the variable was available however, you'd never fallback, and thus the substitution would work. (I guess this is what happens in Safari.)

[1] https://drafts.csswg.org/css-values/#calc-type-checking

Thanks fs!

Closing as WontFix as per comment 10.