170834 2017-04-13 16:47:06 -0700 background-size with 2nd value is 'auto' and the image has no intrinsic size and no intrinsic ratio incorrectly rendered 2024-12-01 19:28:40 -0800 1 1 1 Unclassified WebKit CSS Safari 10 Unspecified Unspecified NEW https://bugs.webkit.org/show_bug.cgi?id=243773 InRadar, WPTImpact P2 Normal --- 1 phiw2 webkit-unassigned ahmad.saleem792 browserbugs2 karlcow simon.fraser tobi webkit-bug-importer zalan oldest_to_newest 1297205 0 phiw2 2017-04-13 16:47:06 -0700 Example URL: http://www.gtalbot.org/BrowserBugsSection/CSS3Backgrounds/draft-background-size-one-value-percent-0xx.xht Per CSS3 - backgrounds: https://drafts.csswg.org/css-backgrounds/#the-background-size For background-size: > [ <length-percentage> | auto ]{1,2} > The first value gives the width of the corresponding image, the second value its height. If only one value is given the second is assumed to be ‘auto’. further, for “auto”, the text notes: > An ‘auto’ value for one dimension is resolved by using the image's intrinsic ratio and the size of the other dimension, or failing that, using the image's intrinsic size, or failing that, treating it as 100%. For a gradient (as in the example), the “image” has no intrinsic size, thus 100% should be used. That is what Firefox / Gecko does. Chrome and Safari are wrong. one <percent> value http://www.gtalbot.org/BrowserBugsSection/CSS3Backgrounds/draft-background-size-one-value-percent-0xx.xht or one <length> value http://www.gtalbot.org/BrowserBugsSection/CSS3Backgrounds/draft-background-size-one-value-0xx.xht What is the expected behavior? Filled green square and no red What went wrong? sliver of green and large area of red (related discussion on the CSS WG list: https://lists.w3.org/Archives/Public/www-style/2017Apr/thread.html#msg29 1297208 1 phiw2 2017-04-13 16:49:14 -0700 Equivalent Blink bug: https://bugs.chromium.org/p/chromium/issues/detail?id=711489 1297283 2 browserbugs2 2017-04-13 20:01:32 -0700 2 additional tests with identical actual results (incorrect behaviors): background-size: 10% auto; http://www.gtalbot.org/BrowserBugsSection/CSS3Backgrounds/draft-background-size-percent-auto-no-intrinsic-0xx.xht background-size: 10px auto; http://www.gtalbot.org/BrowserBugsSection/CSS3Backgrounds/draft-background-size-length-auto-no-intrinsic-0xx.xht 2 additional tests with identical actual results (incorrect behaviors) *_using SVG image_* with no intrinsic ratio: background-size: 10% auto; http://www.gtalbot.org/BrowserBugsSection/CSS3Backgrounds/draft-background-size-percent-auto-no-intrinsic-0xy.xht background-size: 10px auto; http://www.gtalbot.org/BrowserBugsSection/CSS3Backgrounds/draft-background-size-length-auto-no-intrinsic-0xy.xht 1297710 3 webkit-bug-importer 2017-04-15 17:41:35 -0700 <rdar://problem/31646443> 1301570 4 simon.fraser 2017-04-26 07:28:52 -0700 Need to fix RenderBoxModelObject::calculateFillTileSize) which calls RenderBoxModelObject::calculateImageIntrinsicDimensions() which has this: // A generated image without a fixed size, will always return the container size as intrinsic size. if (image->isGeneratedImage() && image->usesImageContainerSize()) 1305307 5 browserbugs2 2017-05-05 14:13:29 -0700 The summary (title) of this bug report should say *_background-size_* and not background-position! All 6 tests mentioned in this bug report are testing and were indeed testing *_background-size_* and not background-position. So, I tuned accordingly the text in the 6 tests and I updated the summary text of this bug report. 1423529 6 tobi 2018-05-14 01:20:20 -0700 It would be great if this could get fixed 1864437 7 browserbugs2 2022-04-26 07:23:27 -0700 Related links - - - - - - - Added 4 background-size (with no intrinsic and no ratio) tests https://github.com/web-platform-tests/wpt/pull/26599 http://wpt.live/css/css-backgrounds/background-size-041.html https://wpt.fyi/results/css/css-backgrounds/background-size-041.html?label=experimental&label=master&aligned http://wpt.live/css/css-backgrounds/background-size-042.html https://wpt.fyi/results/css/css-backgrounds/background-size-042.html?label=experimental&label=master&aligned http://wpt.live/css/css-backgrounds/background-size-043.html https://wpt.fyi/results/css/css-backgrounds/background-size-043.html?label=experimental&label=master&aligned http://wpt.live/css/css-backgrounds/background-size-044.html https://wpt.fyi/results/css/css-backgrounds/background-size-044.html?label=experimental&label=master&aligned 2077826 8 karlcow 2024-11-26 22:05:07 -0800 Only 43, and 44 are marked as FAIL in Safari currently. http://wpt.live/css/css-backgrounds/background-size-043.html https://wpt.fyi/results/css/css-backgrounds/background-size-043.html?label=experimental&label=master&aligned http://wpt.live/css/css-backgrounds/background-size-044.html https://wpt.fyi/results/css/css-backgrounds/background-size-044.html?label=experimental&label=master&aligned 2078396 9 karlcow 2024-12-01 19:28:40 -0800 https://searchfox.org/wubkat/rev/d45649fa32a499702c30474e94bd6843c4c67849/Source/WebCore/rendering/RenderBoxModelObject.cpp#787-789 // A generated image without a fixed size, will always return the container size as intrinsic size. if (!image->imageHasNaturalDimensions()) return LayoutSize(positioningAreaSize.width(), positioningAreaSize.height()); Probably should be testing for SVGElement and intrisic sizing too. https://searchfox.org/wubkat/source/Source/WebCore/svg/SVGSVGElement.cpp#639