Rules which select the same element with the same zoom: value result in sizes which aren't zoomed |
||||||
Issue descriptionChrome Version : 64.0.3282.119 OS Version: OS X 10.13.3 URLs (if applicable) : http://jsbin.com/simolabega/1/edit?html,output Other browsers tested: Add OK or FAIL after other browsers where you have tested this issue: Safari: OK Version 11.0.3 (13604.5.6) What steps will reproduce the problem? 1. Open the attached file What is the expected result? Both red and green DIVs are the same size What happens instead of that? The red DIV is larger than the green DIV Please provide any additional information below. Attach a screenshot if possible. UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.119 Safari/537.36 This bug happens when there's two selectors which select the same element and each rule has a zoom property with the same value: * If there's only one selector, the size is correct. * If there are two rules and the zoom values are different, the size is correct. * The selectors don't have to be identical, they just have to select the same element. * There's nothing magic about 50%, this reproduces with many (probably any) zoom. * The computed zoom is correct. This doesn't seem to be related to style sharing, this reproduces even with one element and one rule with a compound selector: <http://jsbin.com/muvulopoqo/1/edit?html,output> <style> .bad, .good { zoom: 50%; } </style> <body> <div style="width: 200px; height: 25px; background: red; color: white;" class="bad good"> I should be small </div>
,
Jan 31 2018
Able to reproduce the issue on reported chrome version 64.0.3282.119 and on the latest canary 66.0.3335.0 using Windows 10, Ubuntu 14.04 and Mac 10.13.1. As the issue is seen from M60(60.0.3072.0) considering it as non-regression and marking it as Untriaged. Thanks!
,
Jan 31 2018
,
Jan 31 2018
,
May 11 2018
,
May 11 2018
Happens because we always reset the _effective_ zoom to that of the parent when applying the zoom value. Then, we recompute the effective zoom only if the zoom value we are about to apply is different from the current zoom value. I.e. 'zoom' is up to date, but 'effective zoom' is incorrectly reset to whatever the parent has. Thanks for the test case. :)
,
May 14 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d947162ed2175e3a226b18fbe2dc5dabbb228c34 commit d947162ed2175e3a226b18fbe2dc5dabbb228c34 Author: Anders Hartvoll Ruud <andruud@chromium.org> Date: Mon May 14 10:13:36 2018 Ensure correct effective zoom when zoom is applied. This fixes a bug where the application of 'zoom' would be ignored, because: the effective zoom was reset in preparation of applying the zoom, yet we did not apply the zoom if the incoming value was equal the current value. This means if you apply the same zoom value twice to the same element, the effective zoom of that element becomes the parent's effective zoom. This patch fixes this by setting the effective zoom from the style resolver directly, instead of doing it inside ComputedStyle::SetZoom and _hoping_ that ComputedStyle::EffectiveZoom() currently returns the right value. Note: The 'state.SetZoom(1.0f)'-ery is there to maintain the behavior in which the effective zoom becomes the parent's zoom whenever zoom:0[%] is used. Note2: The return value of ComputedStyle::SetZoom is probably not interesting anymore. In fact, 'zoom' could probably be de-specialized. (Separate patch). R=dominicc@chromium.org, futhark@chromium.org Bug: 807503 Change-Id: I50cb7c1116da463fa59b745d2d31ef942be9085b Reviewed-on: https://chromium-review.googlesource.com/1054075 Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Anders Ruud <andruud@chromium.org> Cr-Commit-Position: refs/heads/master@{#558246} [add] https://crrev.com/d947162ed2175e3a226b18fbe2dc5dabbb228c34/third_party/WebKit/LayoutTests/fast/css/zoom-stable-effective-expected.html [add] https://crrev.com/d947162ed2175e3a226b18fbe2dc5dabbb228c34/third_party/WebKit/LayoutTests/fast/css/zoom-stable-effective.html [modify] https://crrev.com/d947162ed2175e3a226b18fbe2dc5dabbb228c34/third_party/blink/renderer/core/css/resolver/style_builder_custom.cc [modify] https://crrev.com/d947162ed2175e3a226b18fbe2dc5dabbb228c34/third_party/blink/renderer/core/css/resolver/style_resolver.cc [modify] https://crrev.com/d947162ed2175e3a226b18fbe2dc5dabbb228c34/third_party/blink/renderer/core/css/resolver/style_resolver_state.cc [modify] https://crrev.com/d947162ed2175e3a226b18fbe2dc5dabbb228c34/third_party/blink/renderer/core/style/computed_style.h
,
May 14 2018
,
May 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/5a719a247a38a3c9f3b51bc64225b61a8c890f98 commit 5a719a247a38a3c9f3b51bc64225b61a8c890f98 Author: Anders Hartvoll Ruud <andruud@chromium.org> Date: Tue May 15 13:22:20 2018 Generate ComputedStyle::SetZoom. The return value is useless, so might as well use the generated function. R=futhark@chromium.org Bug: 807503 Change-Id: I402edb2b2a70e5ec14e06c3be0fcf5836b46c083 Reviewed-on: https://chromium-review.googlesource.com/1057710 Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Anders Ruud <andruud@chromium.org> Cr-Commit-Position: refs/heads/master@{#558684} [modify] https://crrev.com/5a719a247a38a3c9f3b51bc64225b61a8c890f98/third_party/blink/renderer/core/css/CSSProperties.json5 [modify] https://crrev.com/5a719a247a38a3c9f3b51bc64225b61a8c890f98/third_party/blink/renderer/core/style/computed_style.h
,
May 16 2018
Able to reproduce the issue on chrome version 64.0.3282.119 (build withtout fix) Verified the fix on Windows 10, Mac 10.13.3 and Ubuntu 14.04 using Chrome version #68.0.3432.0 as per the comment #0. Attaching screenshot for reference. Observed that "Both red and green DIVs are the same size." Hence, the fix is working as expected, adding Verified labels Thanks...! |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by krajshree@chromium.org
, Jan 31 2018