Issue metadata
Sign in to add a comment
|
background-size: cover scales incorrectly when used with background-attachment:fixed
Reported by
r...@gospacecraft.com,
Mar 1 2016
|
||||||||||||||||||||||
Issue descriptionExample URL: http://s.codepen.io/RwwL/debug/eZmVPd Steps to reproduce the problem: 1. set a background image on a page's HTML element 2. apply css background-size: cover and background-attachment: fixed 3. add content to the page until it becomes longer than the viewport 4. view in Chrome for Android What is the expected behavior? The previous behavior in this case was the the background image would be stretched to the full height of the page and it would not remain fixed while scrolling. This was not necessarily the expected behavior for many developers because we usually want/expect the image to be fixed to the *visible* viewport, like the same CSS combination works on desktop browsers, but this has long been the case with mobile browsers and this is not the reason for this report. What went wrong? When the page gets longer than the visible screen height, the image remains (nearly) fixed when scrolling, but it also gets stretched as if it's covering an area many times the height of the screen. Please see the attached test case link. The 1200x800 (landscape) background image has a lime green border all the way around it, and horizontal lines that mark 10%, 25%, 50%, 75%, and 90% of the height of the background image. When this image is applied with background-size: cover on a portrait-oriented phone, all of those horizontal lines and the top and bottom borders should always be visible. They *are* all visible when first loading this page on a phone or in the Chrome Dev Tools device emulator, but when you use the button to add a few paragraphs and make the page longer, look how much bigger the background image gets stetched — way bigger than needed to cover the page height. Mobile/responsive web developers have become accustomed to the stretching of background images to the full height of the page on Android and iOS, and have come up with some workaround that can occasionally help, but this is a much more severe situation. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? Yes Can't say for sure, but definitely pretty recently. Does this work in other browsers? Yes Chrome version: 48.0.2564.95 Channel: stable OS Version: 6.0.1 Flash Version: Shockwave Flash 20.0 r0 Please let me know if I can provide any additional details.
,
Mar 2 2017
This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue. The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 3 2017
,
Apr 16 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 16 2018
The codepen example has "expired". Any chance you can re-enable it for us? Even better, attach the example to the bug so it will never go away. Otherwise we can't act.
,
Apr 16 2018
Maybe there was a temporary outage or glitch at codepen, but the original example still works for me, no login required. Attaching HTML file just in case. Looking at this again for the first time in over a year, it does appears to me this might have been fixed somewhere along the way, though.
,
Apr 17 2018
Yep, it does seem to have been fixed. Thanks for posting the example.
,
Apr 30 2018
The NextAction date has arrived: 2018-04-30 |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by chrishtr@chromium.org
, Mar 1 2016Status: Available (was: Unconfirmed)