css rule using env() function not ignored in all cases
Reported by
davidmax...@gmail.com,
Oct 23
|
|||||||||||
Issue descriptionSteps to reproduce the problem: 1. open https://jsbin.com/cifitowugi in Samsung Internet 7.4.00.70 or Chromium 59 2. open chrome dev tools 3. examine css for the body element What is the expected behavior? I expect margin-top to have 'invalid property value' and be ignored, like the margin-left value - due to it including the 'env()' function, which clearly isn't recognised. What went wrong? margin-left is ignored, but not margin-top. All rules including 'env()' should be ignored. Did this work before? N/A Does this work in other browsers? N/A Chrome version: samsung internet 7.4.00.70 Channel: stable OS Version: P Flash Version: This works fine in latest chrome since env() is now implemented, but I want to make sure unrecognised functions are also ignored in situations like the in the margin-top example that seems to have slipped through the net.
,
Oct 24
Tested the issue on android and below are the observations Steps to reproduce: -------------------------- 1. Launched chrome and navigated to https://jsbin.com/cifitowugi 2. Connected to desktop and opened chrome://inspect/#devices , inspected above page and Filtered for margin and observed below result margin: 0; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; Chrome version: 60.0.3112.113, 70.0.3538.64, 72.0.3589.0 OS: Android 9.0 Android device: Pixel 2 XL @davidmaxwaterman: Please check the above steps and let us know if this is the issue you are addressing. Thanks!
,
Oct 24
New jsbin - same but with me logged in so it doesn't expire: https://output.jsbin.com/xevuquz/1 I think you're looking in the 'Computed' css values, rather than the 'Styles'. I'll attach a screenshot of what I mean. Essentially, devtools marks the margin-left as an invalid property value with the yellow warning triangle, as well as striking it through; but it does nothing to the margin-top which is supposed to be ignored as well since it contains the unimplemented 'env()' function. Interestingly, if you replace the var() in that property value with a constant, like '100vh', then dev tools *does* mark it as invalid: calc(100vh - env(safe-area-inset-top) - env(safe-area-inset-bottom)) but: calc(val(--max-was-here) - env(safe-area-inset-top) - env(safe-area-inset-bottom)) isn't. That makes me think that the presence of the 'var' function is causing dev tools to think it is valid.
,
Oct 24
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 25
davidmaxwaterman@ -- Thanks for providing the feedback. The provided link(https://output.jsbin.com/xevuquz/1) in the C#3 redirects to the blank page. However, tried to inspect elements as mentioned in C#2 and have observed the same results. Attached the screenshot for the same. Which gives the values of the 'Styles'. Request you to take a look into above comments and let us know if anything is missed from our end. If possible please share a screencast of the actual issue for the better understanding of the issue. Thanks!
,
Oct 25
Yes, the URL is correct - the page is blank, but the <body> has style applied to demonstrate the problem (in your screenshot, it looks like you're examining the code for jsbin, which isn't correct - that's why I used the 'live preview' feature which is the new URL). If you open https://output.jsbin.com/xevuquz/1 in chrome on desktop with devtools (right click on the white background and select 'inspect') and then select the <body> tag, you can examine its style to see the two margin properties. Both are *not* disabled, since newer versions of chrome support 'env()'. If you do the same on samsung internet, connecting devtools via chrome://inspect, then you'll see one is disabled while the other is not (as shown in my screenshot). I imagine that, if you have the 59 version of chromium on desktop, you might be able to see the problem at https://output.jsbin.com/xevuquz/1, or you could just apply those two css rules to any page and you'll see the same effect. Perhaps I'll try to make a video.
,
Oct 25
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 25
Here's a short video of me showing the problem. I hope that works. https://photos.app.goo.gl/KQMd2XAwzfUBr1Mx9
,
Oct 26
davidmaxwaterman@ -- I have taken screenshots of Dev Tools when Chrome #64.0.3282.137 and latest Chrome #70.0.3538.64 installed on DUT. Could you please confirm which is the expected behavior. That would help us in further triaging the issue. Thanks in advance!
,
Oct 26
Ah, great, you've reproduced it. The issue is this: 1. In #64, chrome hasn't implemented env() so it should (iinm) ignore all rules that include that function. It ignores margin-left, but not margin-top. 2. In #70, chrome *has* implemented env() so you don't see the problem - it is hidden because env() is now implemented. If some other function is introduced, then (iinm) it will also have the problem shown by #64. So, in order to attempt to reproduce this problem in #70, you'll have to use an unimplemented function. Hrm, thinking about it, Chrome developers are being somewhat tardy about implementing max() and min(), so using one of those should show it in the newest version. Indeed, if I add a rule like the margin-top one, but using max(), it does indeed still show it enabled: margin-right: calc(var(--vh, 1vh) * 100 - max(safe-area-inset-top, safe-area-inset-bottom)); https://output.jsbin.com/xevuquz Dev tools shows this line as 'enabled', but margin-right is just given the value '0': margin-right: calc(var(--vh, 1vh) * 100 - max(safe-area-inset-top, safe-area-inset-bottom)); It should be struck out and have a yellow triangle, like the margin-left rule in #64. Well, that's what I'm claiming anyway - there could be some weird reason why it is like this.
,
Oct 26
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 26
,
Oct 26
I think I made an error in my previous jsbin change....I had missed out the 'env()' functions inside the 'max()' call. It should have been: margin-right: calc(var(--vh, 1vh) * 100 - max(env(safe-area-inset-top), env(safe-area-inset-bottom))); ...and that *is* ruled out, which seems to prove the it is behaving correctly. However, the rule is too complicated, so I've now simplified it and changed both rules to use max() instead of env(). https://output.jsbin.com/xevuquz margin-top: calc(var(--vh, 1vh) * 100 - max(100%, 100px)); margin-left: max(100%, 100px); Notice that martin-top is not ruled out, but margin-left is. IMO, they should both be ruled out and ignored, so have no effect on the style. I have also added another margin-top rule: margin-top: 1000px; and you can see that it has been ruled out and overridden by the later margin-top, which seemed to be computed to '0px'. IMO, margin-top should be 1000px.
,
Oct 30
,
Dec 4
This doesn't look like a DevTools bug, if it is a bug at all. DevTools just reports which properties are being accepted by the CSS engine. I'm not familiar with how unknown functions are supposed to be handled by CSS, but regardless devtools appears to reflect the actual behavior of the page. You can verify this by looking at the value of `window.getComputedStyle(document.body).marginTop`
,
Dec 4
> This doesn't look like a DevTools bug Indeed, perhaps this is wrongly categorised. You might also be correct to question if it is a bug at all. I thought I read somewhere that it should be ignored, but I can't find that anywhere.
,
Dec 10
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by chelamcherla@chromium.org
, Oct 24Labels: Needs-triage-Mobile