Issue metadata
Sign in to add a comment
|
Changing background-position after setTimeout for offscreen background-image
Reported by
j...@dumbwaiterdesign.com,
Apr 5 2017
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Steps to reproduce the problem: You can see the bug by unzipping the attached example.zip and opening index.html in Chrome. The expected behavior is that an image should appear on the page after two seconds, but because of this bug the image won't show until you resize the browser window. What is the expected behavior? The expected behavior is that changing the background-position with JavaScript will show the image. What went wrong? It seems like there's a race condition here because without the setTimeout in the JavaScript everything works fine. It also only breaks if .hero__overlay has position: absolute and if the background-image starts offscreen (background-position: 0 -9999px). Did this work before? N/A Chrome version: 57.0.2987.133 Channel: stable OS Version: OS X 10.11.6 Flash Version: I'm able to work around this by adding the following JavaScript to the end of the init function: var originalImage = hero.style.backgroundImage; hero.style.backgroundImage = 'none'; hero.style.backgroundImage = originalImage;
,
Apr 6 2017
Marking as a regression for now. Bisect please.
,
Apr 11 2017
Bisect?
,
Apr 12 2017
Able to reproduce the issue on Mac 10.12.4 using chrome reported version (Stable)57.0.2987.133 and Canary-59.0.3069.0. Image is not appeared on the page after two seconds (as per attached index.html in zip file). Manual Bisect: Good-54.0.2840.0-Revision-414607 Bad-55.0.2841.0-Revision- 414854 As we observed Good & bad builds in 2 different milestones,providing manual bisect information from Omahaproxy. Change Log: https://chromium.googlesource.com/chromium/src/+log/54.0.2840.0..55.0.2841.0?pretty=fuller&n=10000 Review-Url: https://codereview.chromium.org/2068723002 flackr@ Kindly take a look and please help us to reassign this issue to a right owner if not with respect to this change. Thanks.!
,
May 1 2017
Clearly we are not repainting the background as needed. The change revealed the problem because we are compositing the scrolling contents and hence not repainting them. There is a workaround noted on the bug, so not a P1.
,
May 1 2017
This is probably just a matter of no-invalidation when background-position is modified. I'll actually own it to produce a simple test case. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by ranjitkan@chromium.org
, Apr 6 2017