Issue metadata
Sign in to add a comment
|
background image improperly painted when container is auto positioned and border image present
Reported by
martin-e...@mail.de,
Apr 1 2018
|
||||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
Example URL:
any
Steps to reproduce the problem:
1. Create a div-element
2. Set div.style to {
box-sizing: border-box; width: 400px; height: 200px;
padding: 50px;
background-color: beige;
background-origin: border-box;
background-image: radial-gradient(100px at top, red, yellow, green);
}
3.
What is the expected behavior?
1. The gradient should cover the entire background,
nothing of the beige color should be visible.
2. The center of the gradient circle should match
the middle of the div's top edge.
What went wrong?
1. he gradient does not cover the entire background,
at left and top edge is a 50px wide beige stripe visible.
Does it occur on multiple sites: Yes
Is it a problem with a plugin? No
Did this work before? Yes don't know for shure
Does this work in other browsers? Yes
Chrome version: 65.0.3325.181 Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version:
Since point 2. of the expected behaviour is fulfilled.
it's not an issue of the gradient calculation
but of the background rendering.
Same happens with an image instead of a gradient.
,
Apr 2 2018
Tested the issue on chrome reported version 65.0.3325.181 using Windows-7 & 10 with steps mentioned below: 1) Launched chrome reported version and created .html file with the help of comment# 0 > Steps to reproduce the problem > step-2(attached for reference) 2) Dragged and dropped .html file in chrome, and observed the behaviour of it. Seen same behaviour in both chrome and Firefox. @Reporter: Please find the attached screen cast for reference and let us know if we missed anything in verifying the issue. could you please provide sample test file/URL which reproduces the issue, if possible please provide screen cast of the issue which help in better understanding. Thanks!
,
Apr 2 2018
Sorry, my fault, the testcase was too simple. I played on a two-column page and had some additional styles attached via javascript. I boiled the page down to a minimum to reproduce the issue. It shines up under following conditions: 1. The element sits in a container with a width in percent and above 50%. 2. 1. Container has float: right or 2. Container has float: left or no float and element has margin: auto. 3. The element has a border-image attached. Which sides of the element are affected depends on the settings for its background-repeat. The added cbb-test.html shows 5 cases, the border-image is added too.
,
Apr 2 2018
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
,
Apr 3 2018
,
Apr 3 2018
Tested the issue on chrome reported version using 65.0.3325.181 with steps mentioned below: 1) Launched chrome reported version, dragged and dropped the file(cbb-test.html) provided in comment#3 2) Observed the behaviour of the cbb-test.html file in chrome with the Firefox, seen the same behaviour in both the browsers @Reporter: Please find the attached screen cast for your reference and let us know if we missed anything in verifying the fix, if possible could you please provide the screen cast of the issue which helps us in better understanding. Thanks!
,
Apr 3 2018
The screen cast of comment 6 doesn't show the border-images. The image file must reside in the same folder as the html file, otherwise its url must be adapted. I provide two screenshots (1 Chrome, 1 Firefox) with the issue visible.
,
Apr 3 2018
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
,
Apr 3 2018
Meanwhile found some new facts about the issue: 1. You may cancel the elements padding, it has no influence on the effect. 2. The width of the beige stripes is exactly the provided border-width. 3. The effect disappears if the border-color is defined: transparent. 4. It also disappears if the border-style is defined other than: solid. So its a problem of how the borders are rendered (or not rendered). In case of a borer-image they should not be rendered, but also not cut off parts of the background.
,
Apr 3 2018
This is probably a regression caused by the optimization to avoid painting the background under opaque borders. I'll try to repro and fix.
,
Apr 5 2018
Able to reproduce the issue on reported version 65.0.3325.181, latest chrome 67.0.3388.0 and Beta 66.0.3359.81 using Mac 10.12.6, Ubuntu 14.04 and Windows-10, hence providing Bisect Info Bisect Info: ================ Good build: 65.0.3286.0 Bad build: 65.0.3287.0 You are probably looking for a change made after 522132 (known good), but no later than 522133 (first known bad). https://chromium.googlesource.com/chromium/src/+log/4180c8d1f8ecebfb115caab61b8500dc4ecccee6..d46daceb7047d0ab92a164a062fa26e31baae377 Reviewed-on: https://chromium-review.googlesource.com/809229 @Florin Malita: Please confirm the issue and help in re-assigning if it is not related to your change. Adding ReleaseBlock-Stable for M-66 as we don't have stable refresh for M-65, feel free to remove it if not applicable Thanks!
,
Apr 5 2018
The NextAction date has arrived: 2018-04-05
,
Apr 5 2018
What's totally weird is that this only happens with auto margins, or some other thing that positions the container without an explicit setting. Minimal test case attached. This is not a P1 bug because it is rather unlikely that the given set of circumstances would arise. The reporter is explicitly testing these features, for which we thank them.
,
Apr 5 2018
Actually, this is pretty simple. The reduction in the destination rect for the background is not accounting for the outset of the border image. I suspect that a whole lot of stuff is broken in this regard, because I'm not aware of any place where we consider the border image in background computations.
,
Apr 5 2018
@schenney (comment#14, Summary) It's not an improper sizing of the background image. The screenshot 'cbb-test-Chrome.png' (comment#8) shows the gradients center at elements top edge, only cut off. That means: the sizing is correct, capturing the complete background. Only the backgrounds destination rect is improperly sized.
,
Apr 5 2018
I was thinking of the painting size. I know that all the CSS sizes are right. Anyway, the fix is up for review and will land for M-67. I think I can also explain why the margin needs to be auto. Anything else causes one of the other do-not-optimize conditions to hit.
,
Apr 5 2018
But, you're right, that are very special cases where the issue shines up. A fix would have to account not only the outset but the border image width too. Since the width points from the outermost inwards, the image covers the border area completely if width >= outset, and nothing happens. The issue can only occur if width < outset or image fails loading.
,
Apr 5 2018
If the border image fails to load I think we should paint the otherwise-ignored border as a fallback. Do we do that now? The proposed fix turns off the optimization whenever there is a non-null border image, because we would also get it wrong if the border image was transparent.
,
Apr 5 2018
You're fast. Yes, the border is painted as fallback. And yes, the proposed fix would always be on the safe side.
,
Apr 5 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/55ada2785514d3e227a2d0eae4a9a8248c19d9db commit 55ada2785514d3e227a2d0eae4a9a8248c19d9db Author: Stephen Chenney <schenney@chromium.org> Date: Thu Apr 05 18:34:12 2018 Avoid optimizing the background with border image outsets We attempt to optimize the background image destination rectangle to avoid pointlessly painting under borders, thus allowing more non-tiling image draws. But that breaks when there is a border image with outsets because in that case, despite an opaque border, the background image may not cover the border area. Also clean up the conditional that prevents the optimization. R=fmalita@chromium.org BUG= 827871 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2 Change-Id: Ibd0fb4307fd2d7b7df4421f18fb07da2c669aa79 Reviewed-on: https://chromium-review.googlesource.com/996884 Commit-Queue: Stephen Chenney <schenney@chromium.org> Reviewed-by: Florin Malita <fmalita@chromium.org> Cr-Commit-Position: refs/heads/master@{#548495} [add] https://crrev.com/55ada2785514d3e227a2d0eae4a9a8248c19d9db/third_party/WebKit/LayoutTests/css3/background/background-border-image-auto-margins-expected.html [add] https://crrev.com/55ada2785514d3e227a2d0eae4a9a8248c19d9db/third_party/WebKit/LayoutTests/css3/background/background-border-image-auto-margins.html [modify] https://crrev.com/55ada2785514d3e227a2d0eae4a9a8248c19d9db/third_party/WebKit/Source/core/paint/BackgroundImageGeometry.cpp
,
Apr 5 2018
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by vamshi.kommuri@chromium.org
, Apr 2 2018