Created attachment 142863 [details] This example demonstrates the problem I think i might have found a bug in Chrome 19.0.1084.46 and Safari 5.1.7 (7534.57.2) which is still in the latest nightly build of WebKit. (Not in Firefox, Opera or IE) When setting the size of a background image to zero with the CSS declaration "background-size: 0", WebKit displays the background as if its size was 1 pixel instead of zero (gives same result as "background-size: 1px"). ----- This seems like a bug. (In practice, this affects things such as animating the background-size of an element from JavaScript (my case), for example. It makes it harder to animate the size of the background image from/to the "invisible-state" (zero size). (mouse-over on items in a menu, for example)) I'm not used to reading W3C-specs, but this document at http://www.w3.org/TR/css3-background/#the-background-size seems to suggest that the background image should not be shown when its size is set to 0 (or in other ways resolves to 0): "If the background image's width or height resolves to zero, this causes the image not to be displayed. (The effect is the same as if it had been a transparent image.)". (An older draft (http://www.w3.org/TR/2002/WD-css3-background-20020802/#background-size) was more clear: "A size of zero is allowed, but causes the image not to be displayed. (In particular, it will not be repeated.)")
Was it always this way, or did this regress in some safari/webkit version?
This is the first time i've used the background-size property, so i am afraid i don't know.
The minimum value of size is assumed to be (1,1) in RenderBoxModelObject::calculateFillTileSize which causes the issue. I will create a patch for this.
Created attachment 145386 [details] patch
Comment on attachment 145386 [details] patch Attachment 145386 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12859880 New failing tests: fast/backgrounds/size/zero.html
Created attachment 145425 [details] Archive of layout-test-results from ec2-cr-linux-04 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: ec2-cr-linux-04 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
The minimum size of (1,1) is assumed for background-size as part of https://bugs.webkit.org/show_bug.cgi?id=15750 where it used to hang when the size dimension becomes 0. This is done almost 5 years back and the latest code does not hang when the size is 0. Please let me know whether it makes sense to bring down the minimum value to (0,0). In that case, the failing test fast/backgrounds/size/zero.html needs to be rebaselined.
Created attachment 146158 [details] Patch-Updated Updated the test results of fast/backgrounds/size/zero.html on mac. Skipped for other platforms.
Comment on attachment 146158 [details] Patch-Updated View in context: https://bugs.webkit.org/attachment.cgi?id=146158&action=review > LayoutTests/fast/backgrounds/size/zero.html:8 > + There should be four empty squares with black borders. WebKit should not hang or assert. http://trac.webkit.org/export/120816/trunk/LayoutTests/fast/backgrounds/size/zero.html shows blue squares in Firefox, so this seems like a divergent behavior change. Can you explain?
(In reply to comment #9) > (From update of attachment 146158 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=146158&action=review > > > LayoutTests/fast/backgrounds/size/zero.html:8 > > + There should be four empty squares with black borders. WebKit should not hang or assert. > > http://trac.webkit.org/export/120816/trunk/LayoutTests/fast/backgrounds/size/zero.html shows blue squares in Firefox, so this seems like a divergent behavior change. Can you explain? As per the specification http://www.w3.org/TR/css3-background/#background-size, if the background image's width or height resolves to zero, this causes the image not to be displayed. The effect should be the same as if it had been a transparent image. But looks like Firefox, Opera and IE shows blue squares, which is different from what the spec says. So probably we should not fix it either. I have not tested it on other browsers before submitting the patch. Should I mark this as WONTFIX?
(In reply to comment #10) > (In reply to comment #9) > > (From update of attachment 146158 [details] [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=146158&action=review > > > > > LayoutTests/fast/backgrounds/size/zero.html:8 > > > + There should be four empty squares with black borders. WebKit should not hang or assert. > > > > http://trac.webkit.org/export/120816/trunk/LayoutTests/fast/backgrounds/size/zero.html shows blue squares in Firefox, so this seems like a divergent behavior change. Can you explain? > > As per the specification http://www.w3.org/TR/css3-background/#background-size, if the background image's width or height resolves to zero, this causes the image not to be displayed. The effect should be the same as if it had been a transparent image. > > But looks like Firefox, Opera and IE shows blue squares, which is different from what the spec says. So probably we should not fix it either. I have not tested it on other browsers before submitting the patch. Should I mark this as WONTFIX? No. If browsers differ from the spec, then we either need to fix the spec, or fix the browsers. You should email www-style about this issue, if you really think that browsers are diverging from what the spec says.
Test results I mentioned on comment #10 was not correct. Apologies. http://trac.webkit.org/export/120816/trunk/LayoutTests/fast/backgrounds/size/zero.html uses -webkit-background-size instead of background-size which causes other browsers to drop the rule and show blue squares. I just retested the testcase again on Firefox and Opera with "background-size" and both of them show empty squares instead of blue except one case where width is defined as 'auto' <div style="background-size: auto 8px;"></div> Webkit computes the width to 0 when the it is 'auto' and with my patch, it shows an empty square. I will check whether this is correct as per spec. The spec says the following for 'auto' value "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%."
Created attachment 148868 [details] Patch-Updated Patch rebaselined. Patch is still valid as per my comment #12 Checked the Webkit behavior for <div style="background-size: auto 8px;"></div> in LayoutTests/fast/backgrounds/size/zero.html. Here the intrinsic size of the background image used is (2,32). Since the width is defined as 'auto', Webkit tries to resolve the width by taking intrinsic ratio and it computes to (2/32) * 8 = 0.5 and it will be rounded to 0 as the size takes int. So showing empty square is correct eventhough it differs from Firefox or Opera. I am bit confused about the spec which says "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%." Does computing the width to 0 using intrinsic ratio can be considered as a failure? If yes, we should take intrinsic width instead of 0 which results in showing blue squares and the behavior matches with other browsers. Please advise.
(In reply to comment #13) > Created an attachment (id=148868) [details] > Patch-Updated > > Patch rebaselined. Patch is still valid as per my comment #12 > > Checked the Webkit behavior for <div style="background-size: auto 8px;"></div> in LayoutTests/fast/backgrounds/size/zero.html. > Here the intrinsic size of the background image used is (2,32). Since the width is defined as 'auto', Webkit tries to resolve the width by taking intrinsic ratio and it computes to (2/32) * 8 = 0.5 and it will be rounded to 0 as the size takes int. So showing empty square is correct eventhough it differs from Firefox or Opera. > > I am bit confused about the spec which says "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%." Does computing the width to 0 using intrinsic ratio can be considered as a failure? If yes, we should take intrinsic width instead of 0 which results in showing blue squares and the behavior matches with other browsers. Please advise. I'm ready to r+ this. Levi, Emil could you comment on specifically this last behavior here? Does this match your understanding?
(In reply to comment #14) > I'm ready to r+ this. Levi, Emil could you comment on specifically this last behavior here? Does this match your understanding? My understanding is that computing the width to zero using the intrinsic ratio should not be considered a failure. It is an interesting question though and the spec isn't terribly clear on the exact definition.
Comment on attachment 148868 [details] Patch-Updated View in context: https://bugs.webkit.org/attachment.cgi?id=148868&action=review Am I correct in understanding that we now match all other browsers except one square, where we diverge in a way which you believe to be acceptable/unspecified? Could you please update zero.html so we can in the future compare against other browsers (if this comes up again). Do we need a bug about our final point of divergence here? > LayoutTests/fast/backgrounds/size/zero.html:11 > <div style="-webkit-background-size: 0 0;"></div> > <div style="-webkit-background-size: 0 32px;"></div> Don't you want to change these to background-size so we can compare with other browsers?
Created attachment 149581 [details] patch Updated -webkit-background-size to background-size
(In reply to comment #16) > (From update of attachment 148868 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=148868&action=review > > Am I correct in understanding that we now match all other browsers except one square, where we diverge in a way which you believe to be acceptable/unspecified? Yes, Tested on Firefox and Opera, but did not get a change to test with IE. >Could you please update zero.html so we can in the future compare against other browsers (if this comes up again). Do we need a bug about our final point of divergence here? I already sent a mail to www-style WG asking for clarification(it may take a while to show up in the archive as my e-mail id is not authorized with www-style). I will create a bug if necessary based upon the discussion. > > > LayoutTests/fast/backgrounds/size/zero.html:11 > > <div style="-webkit-background-size: 0 0;"></div> > > <div style="-webkit-background-size: 0 32px;"></div> > > Don't you want to change these to background-size so we can compare with other browsers? Done.
Comment on attachment 149581 [details] patch Thank you!
Comment on attachment 149581 [details] patch Clearing flags on attachment: 149581 Committed r121296: <http://trac.webkit.org/changeset/121296>
All reviewed patches have been landed. Closing bug.
The tests from this bug are asserting on Mac. Tracker bug: https://bugs.webkit.org/show_bug.cgi?id=90071
(In reply to comment #18) > (In reply to comment #16) > > (From update of attachment 148868 [details] [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=148868&action=review > > > >Could you please update zero.html so we can in the future compare against other browsers (if this comes up again). Do we need a bug about our final point of divergence here? > > I already sent a mail to www-style WG asking for clarification(it may take a while to show up in the archive as my e-mail id is not authorized with www-style). I will create a bug if necessary based upon the discussion. > > Reply by Tab Atkins Jr. on the www-style thread (http://lists.w3.org/Archives/Public/www-style/2012Jul/0040.html) "The "failing that" clauses are for when some of the information in the previous clause doesn't exist; for example, if the image doesn't have an intrinsic ratio, it'll fail the first clause, and if it doesn't have an intrinsic size in the missing dimension at all, it'll fail the second clause too. If the image has the necessary dimensions for a clause, but applying the clause causes the browser to round that dimension to zero, it'll fall into the "zero dimension" clause at the very end of the property's definition, which makes it not be displayed." So it looks like WebKit is doing it correctly and don't need a new bug.