button styles break parent background-size painting
Reported by
daniel.u...@solarishealth.com,
Oct 26 2017
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Steps to reproduce the problem: 1. Hover cursor over each div containing a button What is the expected behavior? The background-size of each div should transition to 100% width. What went wrong? Some divs that have certain styles applied to their child button prevent the new background-size from painting. Did this work before? Yes Does this work in other browsers? Yes Chrome version: 61.0.3163.100 Channel: stable OS Version: 10.0 Flash Version: Each div has a child button. Each one has a different set of styles applied. Each one changes the background-size of the div when hovered (this bug is also present when styling on changes to attributes or classes, not just hover). Buttons with the following styles applied prevent painting of the new background-size for their parent div: border-color: [any value] background-color: [any value] display: block + border-width: [any value] For those divs exhibiting this bug, when clicking a button, the correct background-size will be painted and continue to work correctly until clicking elsewhere. Manually applying :focus in dev tools does not appear to influence this behaviour. This bug is not currently present in IE 11, Edge, Firefox or Safari. I'm not entirely sure when this regressed as it took a while to reduce to this test case, but it was definitely functioning correctly at one time (sometime after the fork from WebKit).
,
Oct 27 2017
Able to reproduce this issue on reported version 61.0.3163.100, latest stable 62.0.3202.75 and latest canary 64.0.3251.0 using Win 7, Win 10 This issue is seen from M50 i.e; 50.0.2661.0. Hence considering this issue as Non-regression and marking as Untriaged. NOTE: Issue is not seen on Mac 10.12.6
,
Oct 27 2017
,
Dec 27 2017
Routing style team to triage this. Feel free to get it back to forms or button element is it is more appropriate.
,
Dec 27 2017
Computed style changes accordingly, and there's a paint flash of the correct area in the inspector. Guessing Blink>Paint.
,
Dec 27 2017
This is a bug in the optimizations to determine whether backgrounds are obscured (and therefore not painted).
,
Dec 28 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0a3e23b889a3b94d2a8f849069d53709dec8cbd3 commit 0a3e23b889a3b94d2a8f849069d53709dec8cbd3 Author: Chris Harrelson <chrishtr@chromium.org> Date: Thu Dec 28 04:11:43 2017 [PE] Invalidate the box's obscuration status when invalidating paint. Previously it would only invalidate parents, but the box itself may also change status. Bug: 778688 Change-Id: Ia4efbb18b2e41cd45882486e9863e6b2779798ca Reviewed-on: https://chromium-review.googlesource.com/845127 Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org> Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Cr-Commit-Position: refs/heads/master@{#526272} [add] https://crrev.com/0a3e23b889a3b94d2a8f849069d53709dec8cbd3/third_party/WebKit/LayoutTests/paint/invalidation/background-obscured-change-invalidate-expected.html [add] https://crrev.com/0a3e23b889a3b94d2a8f849069d53709dec8cbd3/third_party/WebKit/LayoutTests/paint/invalidation/background-obscured-change-invalidate.html [modify] https://crrev.com/0a3e23b889a3b94d2a8f849069d53709dec8cbd3/third_party/WebKit/Source/core/layout/LayoutBox.cpp
,
Dec 28 2017
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by gracec@chromium.org
, Oct 27 2017Status: Untriaged (was: Unconfirmed)